Wazi » Features

Securing SSL/TLS with Secure Renegotiation

Joe Backo — Fri, 05 Mar 2010 21:55:48 +0000

In November of this year an energetic software engineer exposed a flaw in the current standard for the SSL/TLS protocol. This flaw impacted all implementations of SSL/TLS. Since SSL/TLS is used throughout the web in everything from electronic commerce to online banking, recent reports of the flaw have prompted questions about a patch or fix in popular SSL/TLS implementations such as OpenSSL. The vulnerability works in such a way as to allow what is known as a “man-in-the-middle” attack to be conducted with the possibility of exposing account information including passwords. As one can imagine, this sort of security exploit and its potential ramifications has a far-reaching impact – particularly on enterprises that use open source software in production systems.

An interim fix has been posted that takes the drastic step of simply shutting off all SSL/TLS renegotiation. This bulk approach is not ideal for many enterprises, as it removes a feature that is often required to use their sites effectively. The code for this interim fix is included in OpenSSL release 0.9.8l. The more effective fix, and one that was recently approved by the IETF Security Working Group, is included in OpenSSL 0.9.8m, released on February 25th, 2010. The fix changes OpenSSL’s default behavior to use secure renegotiation unless overridden. Previous versions of OpenSSL used the opposite default, requiring secure negotiation to be turned on manually. This change should address the problem for the majority of OpenSSL users. However, by changing the default behavior, users of OpenSSL who had already been using more complex negotiation schemes may need to update their settings.

A future version (2.2.15) of the Apache Httpd web server will incorporate flags that can be used to tune the SSL/TLS renegotiation feature. This code has not been released at this time.

Additional Resources

More specific information and code can be obtained through the resources listed below.

Getting Started with Java EE 6

Mert — Wed, 27 Jan 2010 20:04:54 +0000

In this tutorial we’ll update you on the world of Java EE 6 with the help of a Twitter-like demo application we’ve code-named wallfriend. The demo application contains JSF 2.0, PrimeFaces, CDI and Weld as well as Hibernate Validator frameworks.

Before You Start

Our tutorial assumes that you’re familiar with the following technologies:

JavaServer Faces (JSF) and Facelets
Dependency Injection Mechanism
Bean Validation

You’ll also need to install the following applications in order to build the demo application from scratch, or to run it on your local machine:

Java 6 (Java SDK 1.6) or greater
NetBeans 6.8 bundled with GlassFish 3
Maven, preferably the latest version 2.2.1 (Netbeans ships with Maven 3.0-SNAPSHOT, so that can also be used)

Meat & Potatoes

What’s New with Java EE 6?

Java EE 6 specification was finalized in December of 2009, bringing new and updated features to the world of enterprise application development. It introduces the profile approach, meant to focus both developers and applications on particular parts of the Java EE 6 platform. The first profile defined by the expert group is the Java EE 6 web profile, which attempts to specify the minimal configuration targeted for the development of typical web applications. Here are the elements of the web profile, with a few that we’ve chosen to explain in detail.

Servlet 3.0
In web frameworks, servlets are used as an entry point to handle all incoming requests, so it could be said that they are the core elements of web-based applications. The new 3.0 version (specification JSR-315) offers innovative features like ease of development with annotations (@Servlet, @ServletFilter, @ServletContextListener) and annotations for restful services like @GET, @POST and more. It also offers pluggability and extensibility. The main aim here is to attain zero-configuration when working with other frameworks and libraries. Toward this end, a new xml tag definition called can be used to apply this feature. The web fragments, which are to be stored inside the jars of their respective libraries, will be merged by the container — so there’s no need for the developer to set up any configurations on the web descriptor file. Speaking of pluggability and extensibility, Servlet 3.0 also has a new application programming interface (API) which can be used to add servlets and filters with coding.
JavaServer Pages (JSP) 2.2
ExpressionLanguage (EL) 2.2
Debugging Support for Other Languages (JSR-45) 1.0
Standard Tag Library for JavaServer Pages (JSTL) 1.2
JavaServer Faces (JSF) 2.0
Ever since the release of JSF’s 1.X version, its aim was to be the go-to framework for building user interfaces and web applications. As it gained popularity with many application developers around the world, there was a growing awareness of terrific features like componenting, validation, navigation, i18n and others. However, as with so many wonderful things, flaws and disadvantages became more evident over time — like how complicated it could be to accomplish even a simple task such as creating your own custom JSF component. JSF version 2.0 aims to remedy these flaws by simplifying and easing development and introducing new features, like built-in Ajax support, which will make standard some of what have until now been third party solutions. Here’s a quick summary of the improvements that are part of JSF 2.0.
- Composite components
  Implementing custom JSF components in 1.x is a real burden. You have to implement a UI component and Tag class, with the option of a Renderer for the markup, and then configure all these within faces-config and tld files. JSF 2.0 simplifies the procedure with the composite component approach introduced in Facelets.
- Native Ajax Support
  JSF 2.0 provides built-in support for Ajax with its API and infrastructure. A good example of the useful new components is f:ajax.
- State Saving
  Since JSF 2.0 aims to handle requests partially with classes like PartialViewContext and PartialStateHolder (among others), it also attempts to make use of a partial mechanism to handle state saving. This has been implemented before, by Apache Trinidad, but PartialStateHolder and StateHelper classes provide a more elegant solution. The goal is to have a lightweight version of the saved state going back and forth in response to requests.
- Scopes
  In addition to the request, session and application scopes, 2.0 also introduces view and flash scopes. View-scoped beans have a life span that is longer than a request, but shorter than session-scoped beans. Flash scopes are like the view scopes that will live on a specified view, including the redirects, and will be removed if you’re moving another view.
- Navigation
  In JSF 1.x every navigation rule should be added to faces-config.xml. With version 2.0 implicit navigation can also be used, as in whether or not an outcome corresponds to a view I.D. It’s also possible to perform conditional navigations on a navigation-case. The new tag can be used in faces-config, with an el snippet for conditional navigation. Version 2.0 also makes it easy to retrieve view parameters and assign them to a given property, which in turn makes handling the parameters for GET requests easy. Two new components (h:link and h:button) also support the integration of view parameters. The key benefit of using these components will be bookmarkable URLs.
- Configuration with Annotations
  With JSF 2.0 you can annotate your managed beans with the new @ManagedBean annotation, and you can specify the scope for your beans with @RequestScoped, @SessionScoped, @ViewScoped, @NoneScoped and more. Instead of those, we’ve chosen to use CDI and Weld annotations.
Common Annotations for Java Platform (JSR-250) 1.1
Enterprise JavaBeans (EJB) 3.1 Lite
Java Transaction API (JTA) 1.1
Java Persistence API (JPA) 2.0
In our opinion, the main highlights of this release are the API for criteria queries and the support for validation. There are also some fancy new features like extended map support and ordered list mappings.

Java EE 6 Containers

There are currently two application servers that are compatible with the implementation of Java EE 6: GlassFish Enterprise Server v3 and TMAX JEUS 7. We’ve chosen to stick with GlassFish v3.

So – What’s Up with PrimeFaces?

PrimeFaces is an open source JSF component suite that bundles over 70 components with built-in Ajax support. It’s based on the YUI and jQuery javascripting libraries. It has a simple, lightweight design that is fully compatible with other JSF component libraries. PrimeFaces also supports Ajax Push with a Comet framework, and it has a mobile UI kit known as TouchFaces. Currently, PrimeFaces supports JSF 2.0 with its 2.0.0.RC and 2.0.0-SNAPSHOT releases.

The ability of Java EE 6 to merge web.xml fragments that originate from third-party frameworks makes it unnecessary (in the context of Java EE 6) to do servlet and mapping configurations for PrimeFaces. Primefaces ships with its own web-fragment.xml.

For more information, visit www.primefaces.org.

Contexts and Dependency Injection (CDI)

As stated in Java Specification Request JSR-299, the purpose of this specification is to unify the JSF-managed bean component model with the EJB component model, resulting in a significantly simplified programming model for web-based applications. CDI also makes it possible for JEE elements to interact with each other using the observer pattern, making it a lot easier to work with enterprise beans and transactional support, among other things.

Dependency Injection For Java

JSR 330 is also a part of Java EE 6, offering a set of standard annotations that can be used for dependency injection. In our demo application we’ll use some of these annotations, such as @Named, @Inject, @Qualifier and others.

WELD

Weld is the reference implementation of JSR-299, which is abbreviated as CDI. Weld provides a complete SPI, allowing Java EE containers to use Weld as their built-in CDI implementation. GlassFish 3 (which we’ll use in our demo) ships with Weld.

Bean Validation and Hibernate Validator

The Bean Validation, JSR 303, defines a metadata model and an API for JavaBean validation. The Hibernate Validator is the reference implementation for this specification request. Hibernate Validator’s latest version adds some nice features — things like validation grouping, native integration with JPA v.2 and JSF v.2, an extended annotation set and more.

WallFriend, The Demo APP

Let’s start by creating the project. We’ll do it using the Maven archetype command. It has an interactive mode, so see below for the user input data (in bold).

mvn archetype:generate -DarchetypeCatalog=http://anonsvn.jboss.org
   /repos/weld/archetypes/tags/1.0.0-BETA1

DEV$ mvn archetype:generate -DarchetypeCatalog=http://anonsvn.jboss.org
   /repos/weld/archetypes/tags/1.0.0-BETA1
[INFO] Scanning for projects...
[INFO] Searching repository for plugin with prefix: 'archetype'.
[INFO] ------------------------------------------------------------------
[INFO] Building Maven Default Project
[INFO]    task-segment: [archetype:generate] (aggregator-style)
[INFO] ------------------------------------------------------------------
[INFO] Preparing archetype:generate
[INFO] No goals needed for project - skipping
[INFO] Setting property: classpath.resource.loader.class =>
'org.codehaus.plexus.velocity.ContextClassLoaderResourceLoader'.
[INFO] Setting property: velocimacro.messages.on => 'false'.
[INFO] Setting property: resource.loader => 'classpath'.
[INFO] Setting property: resource.manager.logwhenfound => 'false'.
[INFO] [archetype:generate]
[INFO] Generating project in Interactive mode
[INFO] No archetype defined. Using maven-archetype-quickstart
(org.apache.maven.archetypes:maven-archetype-quickstart:1.0)
Choose archetype:
1: remote -> weld-jsf-servlet-minimal (Weld archetype for creating an
application using JSF 2.0 and CDI 1.0 for Servlet Containers
(Tomcat 6 / Jetty 6))
2: remote -> weld-jsf-jee-minimal (Weld archetype for creating a minimal
Java EE 6 application using JSF 2.0, CDI 1.0 and EJB 3.1 (persistence unit
not included))
3: remote -> weld-jsf-jee (Weld archetype for creating a Java EE 6
application using JSF 2.0, CDI 1.0, EJB 3.1 and JPA 2.0 (persistence
unit included))
Choose a number:  (1/2/3): 2

Here enter 2, for weld-jsf-jee-minimal. And then specify the
groupId-artifactId-packaging for the project.

Define value for groupId: : com.openlogic.wazi
Define value for artifactId: : wallfriend
Define value for package: : war
Confirm properties configuration:
version: 1.0.0-SNAPSHOT
groupId: com.openlogic.wazi
artifactId: wallfriend
package: war
 Y: : Y
[INFO] -------------------------------------------------------------------
[INFO] BUILD SUCCESSFUL
[INFO] -------------------------------------------------------------------
[INFO] Total time: 19 seconds
[INFO] Finished at: Tue Jan 12 21:58:35 EET 2010 [INFO]
Final Memory: 12M/79M [INFO]
-------------------------------------------------------------------

Since this is an archetype project, we can immediately run it from the command line with Maven on an embedded GlassFish:

DEV$ mvn package embedded-glassfish:run
[INFO] Scanning for projects...
[INFO] Searching repository for plugin with prefix: 'embedded-glassfish'.
[INFO] org.apache.maven.plugins: checking for updates from glassfish
[INFO] org.codehaus.mojo: checking for updates from glassfish
[INFO] -------------------------------------------------------------------
[INFO] Building wallfriend
[INFO]    task-segment: [package, embedded-glassfish:run]
[INFO] -------------------------------------------------------------------
[INFO] [resources:resources]
[INFO] Using default encoding to copy filtered resources.
[INFO] [compiler:compile]
[INFO] Compiling 1 source file to /DEV/wallfriend/target/classes
[INFO] [resources:testResources]
[INFO] Using default encoding to copy filtered resources.
[INFO] [compiler:testCompile]
[INFO] Compiling 1 source file to /DEV/wallfriend/target/test-classes
[INFO] [surefire:test]
[INFO] Surefire report directory: /DEV/wallfriend/target/surefire-reports

-------------------------------------------------------
 T E S T S
-------------------------------------------------------
Running TestSuite
Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.369 sec

Results :

Tests run: 1, Failures: 0, Errors: 0, Skipped: 0

[INFO] [war:war]
[INFO] Packaging webapp
[INFO] Assembling webapp[wallfriend] in [/DEV/wallfriend/target/wallfriend]
[INFO] Processing war project
[INFO] Webapp assembled in[162 msecs]
[INFO] Building war: /DEV/wallfriend/target/wallfriend.war
[INFO] [embedded-glassfish:run]
[WARNING] Attempting to build MavenProject instance for Artifact
(org.codehaus.mojo:jboss-maven-plugin:3.0) of type: maven-plugin;
constructing POM artifact instead.
Downloading: http://repository.jboss.org/maven2/org/codehaus/mojo
/jboss-maven-plugin/3.0/jboss-maven-plugin-3.0.pom
Downloading: http://repo1.maven.org/maven2/org/codehaus/mojo
/jboss-maven-plugin/3.0/jboss-maven-plugin-3.0.pom
[WARNING] Attempting to build MavenProject instance for Artifact
(org.apache.maven.plugins:maven-eclipse-plugin:3.0)  of type:
maven-plugin; constructing POM artifact instead.
Downloading: http://repository.jboss.org/maven2/org/apache/maven
/plugins/maven-eclipse-plugin/3.0/maven-eclipse-plugin-3.0.pom
Downloading: http://repo1.maven.org/maven2/org/apache/maven
/plugins/maven-eclipse-plugin/3.0/maven-eclipse-plugin-3.0.pom
Jan 13, 2010 10:36:39 PM com.sun.enterprise.v3.server.AppServerStartup run
INFO: GlassFish v3 (74.2) startup time : Embedded(1228ms)
startup services(1317ms) total(2545ms)
Jan 13, 2010 10:36:39 PM com.sun.enterprise.transaction
.JavaEETransactionManagerSimplified initDelegates
INFO: Using com.sun.enterprise.transaction.jts
.JavaEETransactionManagerJTSDelegate as the delegate
Jan 13, 2010 10:36:40 PM org.glassfish.admin.mbeanserver
.JMXStartupService$JMXConnectorsStarterThread run
INFO: JMXStartupService: JMXConnector system is disabled, skipping.
Jan 13, 2010 10:36:40 PM AppServerStartup run
INFO: [Thread[GlassFish Kernel Main Thread,5,main]] started
Jan 13, 2010 10:36:40 PM org.hibernate.validator.util.Version
INFO: Hibernate Validator null
Jan 13, 2010 10:36:40 PM org.hibernate.validator.engine.resolver
.DefaultTraversableResolver detectJPA
INFO: Instantiated an instance of org.hibernate.validator.engine.resolver
.JPATraversableResolver.
Jan 13, 2010 10:36:41 PM com.sun.enterprise.v3.services.impl
.GrizzlyProxy$2$1 onReady
INFO: Grizzly Framework 1.9.18-k started in: 434ms listening on port 7070
Jan 13, 2010 10:36:58 PM com.sun.common.util.logging
.LoggingConfigImpl openPropFile
INFO: Cannot read logging.properties file.
Jan 13, 2010 10:36:58 PM com.sun.enterprise.web.WebContainer
createHttpListener
INFO: Created HTTP listener embedded-listener on port 7070
Jan 13, 2010 10:36:58 PM com.sun.enterprise.web.WebContainer
configureHttpServiceProperties
WARNING: pewebcontainer.invalid_http_service_property
Jan 13, 2010 10:36:59 PM com.sun.enterprise.web.WebContainer createHosts
INFO: Created virtual server server
Jan 13, 2010 10:36:59 PM com.sun.enterprise.web.WebContainer
loadSystemDefaultWebModules
INFO: Virtual server server loaded system default web module
^[[BJan 13, 2010 10:37:08 PM com.sun.enterprise.security.SecurityLifecycle
INFO: security.secmgroff
Jan 13, 2010 10:37:09 PM com.sun.enterprise.security.ssl.SSLUtils
checkCertificateDates
SEVERE: java_security.expired_certificate
Jan 13, 2010 10:37:09 PM com.sun.enterprise.security.SecurityLifecycle
onInitialization
INFO: Security startup service called
Jan 13, 2010 10:37:09 PM com.sun.enterprise.security.PolicyLoader
loadPolicy
INFO: policy.loading
Jan 13, 2010 10:37:09 PM com.sun.enterprise.security.auth.realm.Realm
doInstantiate
INFO: Realm admin-realm of classtype com.sun.enterprise.security.auth
.realm.file.FileRealm successfully created.
Jan 13, 2010 10:37:09 PM com.sun.enterprise.security.auth.realm.Realm
doInstantiate
INFO: Realm file of classtype com.sun.enterprise.security.auth.realm.file
.FileRealm successfully created.
Jan 13, 2010 10:37:09 PM com.sun.enterprise.security.auth.realm.Realm
doInstantiate
INFO: Realm certificate of classtype com.sun.enterprise.security.auth
.realm.certificate.CertificateRealm successfully created.
Jan 13, 2010 10:37:09 PM com.sun.enterprise.security.SecurityLifecycle
onInitialization
INFO: Security service(s) started successfully....
classLoader = WebappClassLoader (delegate=true; repositories=WEB-INF/classes/)
SharedSecrets.getJavaNetAccess()=java.net.URLClassLoader$7@2d205042
Jan 13, 2010 10:37:09 PM org.jboss.weld.bootstrap.WeldBootstrap
INFO: WELD-000900 SNAPSHOT
Jan 13, 2010 10:37:09 PM org.hibernate.validator.engine.resolver
.DefaultTraversableResolver detectJPA
INFO: Instantiated an instance of org.hibernate.validator.engine
.resolver.JPATraversableResolver.
nullID: /DEV/wallfriend/gfembed6764346819525137279tmp/applications
/wallfriend/ CLASSES: [class war.HelloWorld]

Jan 13, 2010 10:37:10 PM com.sun.faces.config.ConfigureListener
contextInitialized
INFO: Initializing Mojarra 2.0.2 (FCS b10) for context '/wallfriend'
Jan 13, 2010 10:37:14 PM com.sun.enterprise.web.WebApplication start
INFO: Loading application wallfriend at /wallfriend
Hit ENTER to redeploy, X to exit

Once you see the line Hit ENTER to redeploy, X to exit, make a request for http://localhost:7070/wallfriend on your browser. You should get a first look at the archetype application like the one below:

Now, let’s open the project inside NetBeans 6.8. Open NetBeans and click File > New Project and then select Maven / Maven Project with Existing POM from the resulting wizard. This should put the Open Project menu on your screen. Select wallfriend from here and you should see the project in the projects tab:

To run wallfriend inside NetBeans 6.8, you need to make sure that you have Java 1.6 defined as a Java platform, and be sure that wallfriend is also using it. Also, from the Tools > Servers menu, you need to define the Java 1.6 executable for your GlassFish. Netbeans also comes with a Maven 3.0-SNAPSHOT version. So, if you want to use your own external Maven, you must declare it to the IDE from Preferences > Miscellaneous > Maven. After configuring it all, just make a request for http://localhost:8080/wallfriend on your browser. You should see the very same page as you did when you ran the project with the embedded GlassFish.

Adding PrimeFaces to the Project

In order to use the JSF components of PrimeFaces, we first have to add the repo and dependency definitions to the pom.xml of the project. Go ahead and open Project Files > pom.xml in NetBeans and add the following snippets, respectively:


    prime-repo
    Prime Technology Maven Repository
    http://repository.prime.com.tr
    default



    org.primefaces
    primefaces
    2.0.0-SNAPSHOT

Now namespace can be added inside the xhtml’s files for PrimeFaces, xmlns:p=”http://primefaces.prime.com.tr/ui”. As mentioned above, there is no configuration needed in web.xml since PrimeFaces ships with its own web fragment.

Wallfriend – The Implementation

As we said before, wallfriend is a simple write-to-wall application with a basic domain, managed beans, and some xhtml pages. You can check out the source from the Google Code project at http://wallfriend.googlecode.com/svn/trunk/wallfriend. A follow the wall mechanism as well as a restful expose of the wall will be added to the project in the near future.

Since the application was not created from scratch, we have some clean-up to do on the archetype-created application. Go ahead and delete the following folders, because they won’t be used:

Web Pages/WEB-INF/templates
Web Pages/resources
Source Packages / war
Test packages / war

Now let’s go through the parts of the project: The Model, The Managed Beans, and The Views.

The Model

For the domain, we have 3 classes: Wall, Brick and WallFriendContext. Wall and Brick are for defining a master-detail relationship between the posts and the wall. WallFriendContext is the application-scoped bean for storing created walls. It’s marked with the javax.enterprise.context.ApplicationScoped bean.

Wall.java

package com.openlogic.wazi.beans;

import java.util.LinkedList;
import java.util.List;

public class Wall {

    String wallName;

    List bricks = new LinkedList();

    public Wall(String wallName) {
        this.wallName = wallName;
    }

    public void addBrick(String graffiti) {
        bricks.add(0, new Brick(graffiti));
    }

    public String getWallName() {
        return wallName;
    }

    public List getBricks() {
        return bricks;
    }
}

Brick.java

package com.openlogic.wazi.beans;

import java.util.Date;

public class Brick {

    private String graffiti;
    private Date publishDate;

    public Brick(String graffiti) {
        this.graffiti = graffiti;
        this.publishDate = new Date();
    }

    public void init() {
    }

    public String getGraffiti() {
        return graffiti;
    }

    public void setGraffiti(String graffiti) {
        this.graffiti = graffiti;
    }

    public Date getPublishDate() {
        return publishDate;
    }

    public void setPublishDate(Date publishDate) {
        this.publishDate = publishDate;
    }
}

WallFriendContext.java

package com.openlogic.wazi.beans;

import java.util.HashMap;
import java.util.Map;
import javax.enterprise.context.ApplicationScoped;

@ApplicationScoped
public class WallFriendContext {

    private Map walls = new HashMap();

    public void addWall(Wall wall) {
        walls.put(wall.getWallName(), wall);
    }

    public Map getWalls() {
        return walls;
    }
}

The Managed Beans (a.k.a. Contextual Beans)

The managed bean classes are defined by the CDI and implemented by Weld, which ships with the GlassFish server. CDI also needs an empty beans.xml file under the WEB-INF folder, since we’re going to use annotations to define our beans. That’s right — that means they can also be configured with good old fashioned XML.

LoginView is the managed bean of choice for handling wall management and creation/accessing. The annotation javax.enterprise.inject.Model identifies the LoginView as a bean of the model layer, as stated in the MVC pattern. We use javax.inject.Inject to identify injectable constructors, while methods and fields. org.hibernate.validator.constraints.NotEmpty is a validator annotation that specifies that the field wallName cannot be empty.

package com.openlogic.wazi.view;

import com.openlogic.wazi.beans.Wall;
import com.openlogic.wazi.beans.WallFriendContext;
import javax.enterprise.inject.Model;
import javax.faces.context.FacesContext;
import javax.inject.Inject;
import org.hibernate.validator.constraints.NotEmpty;

@Model
public class LoginView {

    @Inject
    private WallFriendContext wallFriendContext;

    @NotEmpty(message="Wall Name cannot be empty")
    private String wallName;

    public String doLogin() {
        Wall wall;
        if (wallFriendContext.getWalls().containsKey(wallName)) {
            wall = wallFriendContext.getWalls().get(wallName);
        }
        else {
            wall = new Wall(wallName);
            wallFriendContext.addWall(wall);
        }
        FacesContext.getCurrentInstance().getExternalContext()
.getRequestMap().put("wall", wall);

        return "myWall";
    }

    public String getWallName() {
        return wallName;
    }

    public void setWallName(String wallName) {
        this.wallName = wallName;
    }
}

MyWallView is the managed bean for handling the paint-a-graffiti on the wall action. The annotation javax.inject.Named, used here, allows you to access the bean using the bean name, with the first letter in lowercase. We use javax.annotation.PostConstruct to mark a method to be invoked after the Dependency Injection is done.

package com.openlogic.wazi.view;

import com.openlogic.wazi.beans.Wall;
import java.io.Serializable;
import javax.annotation.PostConstruct;
import javax.enterprise.context.SessionScoped;
import javax.faces.context.FacesContext;
import javax.inject.Named;
import org.hibernate.validator.constraints.NotEmpty;

@Named
@SessionScoped
public class MyWallView implements Serializable {

    private Wall wall;

    @PostConstruct
    public void init() {
        wall = (Wall) FacesContext.getCurrentInstance()
                  .getExternalContext().getRequestMap().get("wall");
    }

    @NotEmpty(message="Graffiti cannot be empty")
    private String graffiti;

    public String paint() {
        wall.addBrick(graffiti);
        graffiti = "";

        return null;
    }

    public Wall getWall() {
        return wall;
    }

    public void setWall(Wall wall) {
        this.wall = wall;
    }

    public String getGraffiti() {
        return graffiti;
    }

    public void setGraffiti(String graffiti) {
        this.graffiti = graffiti;
    }
}

The Pages

Facelets, JSF 2.0, and PrimeFaces projects are used for the development of views. JSF tags are also commonly used. One different component could be p:growl, which is for viewing the FacesMessages in a Mac-like growl. Also, there is no defined navigation-rule in the faces-config.xml file for navigating from login.xhtml to myWall.xhtml. This is with the implicit navigation mechanism that comes with JSF 2.0. The return string of LoginView#doLogin() method matches the name of the myWall.xhtml view.


      
          WallFriend - Java EE 6 Starter Application

myWall.xhtml page renders the wall posts for a wall, and the user can also write up to the wall.

 
       
          WallFriend - Java EE 6 Starter Application
       
       
          
             
                
                   
                   
                      
                      
                   
                   
                      
                        #{brick.graffiti}

Finishing Up

Java EE 6 is hot, new, and pretty darn cool. In our opinion, as users begin to employ it for upcoming projects, the number of blogposts, samples, and other resources will eventually increase. And with its adoption by the Java Community, we’ll for sure see more Java EE 6-compliant application servers around. Java EE 6 really eases development with its “standardized” features, and the zero-configuration approach apparent in every part of the implementation is really nice, lending an out-of-the-box feeling that’s similar to the .NET environment. It’s not just another java framework!

Best Practices for Creating an Open Source Policy

Stormy Peters — Wed, 25 Feb 2009 23:17:05 +0000

Most companies using open source software know they need an open source policy policy. However, when it comes to creating a policy companies often don’t know where to start and spend months debating policy details and researching options. This guide is intended to help you write an open source software policy. But perhaps more important, it will also help you figure out who to include in the policy creation process so that your company is likely to agree upon and use the open source software policy once it’s been written.

Why do you need an open source software policy?

At first many companies question the need for an open source software policy—primarily because they think it will be too difficult to create. Policy creation does require a lot of work and cooperation, but by following this guide you should be able to create and roll out an open source software policy in less than a month.

Some of the main benefits to having an open source software policy include:

Ensuring the company is in agreement about how to use open source software. Companies often start drafting an open source policy when somebody in management realizes they don’t know how much their IT department or software products depend on open source software. A clearly-stated policy can help ensure that everyone in the company is on board with your open source strategy and that employees feel like they’re empowered to use open source software where appropriate.
Maximizing the benefit of open source software. By creating a policy, you will put processes in place that will enable employees to use open source software effectively as well as share knowledge and workload between teams. For example, three different teams won’t independently figure out how to get support for the same project, and different employees won’t independently evaluate the same upgrade. Having an open source software policy and sharing information across the enterprise will enable your company to maximize the benefits of the open source software it uses.
Minimizing the legal, technical, and business risks of using open source software. Executive management and attorneys are often very concerned about being sued for using open source software, getting caught without sufficient technical support, or receiving bad publicity related to how open source software is used. An open source software policy can not only minimize those risks but also show concerned employees how the company is addressing those needs.

The process of writing an open source policy

The key to writing an open source software policy is just to get started! Companies typically either write, approve, and adopt an open source software policy within a month, or else they spend months working on a policy and yet fail to gain company-wide approval on the finished product. By following these steps you can ensure your company has an approved and adopted policy within a few weeks:

Identify key stakeholders
Get stakeholders to buy into the concept of a policy
Figure out your company’s strategy
Create the first draft of the policy
Get widespread review and acceptance, starting with your stakeholders
Repeat last two steps as necessary

Stakeholders

Your first step—the one important to making sure that your policy is adopted—is to identify the stakeholders in your policy. There are several types, ranging from those who care desperately because you might change their ability to do their job (like developers) to those who care desperately because they think a bad policy might get them fired (like CIOs and those who report to them.) Be sure to include people who you think will disagree with your policy—better to address their disagreements upfront than to have them fight the policy because they don’t like one part of it.

While you’ll have to use whatever strategies work best in your organization, getting all of the stakeholders involved as soon as possible will help your policy get widely adopted more quickly. The more your stakeholders feel like it’s their policy, the better. The best case scenario is if they can say they reviewed it and feel comfortable with you (or whoever is writing the policy) taking care of the details.

As you put together your list of stakeholders you should consider:

Developers—the people who will have to follow the policy
IT staff, as they probably download and use open source software
Managers of teams that use open source software
Attorneys
CIO and staff
Technical architects; many companies have architectural committees, and they should be involved

You’ll probably have two groups of stakeholders: the key stakeholders who will need to approve the policy, and the people who will be affected by the policy.

Strategy

An open source software policy is meant to help your company’s strategy—both its general strategy and its open source strategy.

For example, you might see open source software as a way to reduce your IT costs. In this case your strategy should not be to “use as much open source software as possible,” but rather to “reduce IT costs by using open source software.” This will enable all of your employees to make the right decision when it comes to choosing between open source and proprietary solutions. The policy will then help your company reduce IT costs—not just by encouraging the use of open source software that has no licensing fees associated with it, but by also leveraging the preexisting open source knowledge of your IT staff.

On the other hand, you might want to build an online community around your company’s product. In this case your strategy might be to use open source software in order to encourage outside developers to help build out features that enable your community to grow. Your interest is in the community, not in making money through software sales, so you might even want to open source your own software and grow a community around it.

Identifying your open source strategy upfront will not only help you figure out your policy, but it will also help you explain to others why it’s the right policy for your company.

Here’s an example of what an open source strategy statement might look like:

Background Statement

Many open source software policies start by talking about the problem they’re trying to solve. Whether or not you need this section probably depends on your company. You may need this section if:

Management doesn’t know how much open source software the company uses or depends on.
There are widely varying opinions on how much open source software is used.
There’s an open source software rule or policy that conflicts with reality (e.g., “No open source allowed,” but your IT infrastructure is built upon open source software).
There are big disagreements on how the company should use open source software.

If you decide you need a background statement, make it brief. Some key things to include in the background statement (if you know them) are:

How much open source software the company currently uses.
How much open source software has or will save you—not just monetary savings, but also consider reductions in development time, consulting time, learning curves, and so on.
Any risks to be aware of—for example, your 24×7 website depends on an open source software package for which there is currently no defined support process.

A background statement in an open source policy might look like this:

Scope

Your company may have many policies, and it may be obvious who they cover. However, with open source software policies it is often necessary to define not only who is covered but what is covered.

Who’s Covered

Most companies with an open source software policy adopt the policy company-wide. However, for many organizations it makes more sense to have a very brief company policy that simply states the strategy and provides some general guidelines for how to use open source software. Then, each division is allowed to elaborate and expand on the policy to meet its needs. In other cases, a particular division creates a policy and later tries to get the company as a whole to adopt it.

Don’t forget to specify subsidiaries and agents in this definition. You might want to consult with an attorney about whether giving open source software to the company’s agents or subsidiaries is considered distribution, as distribution triggers clauses in some open source software licenses.

Also, you might want to specify whether or not the open source software policy applies to everyone or just to employees in certain jobs or roles. For example, you may not care how your IT staff uses open source software in the internal IT environment, but you want to ensure that all software developers working on applications that are distributed to others are aware of the open source software policy.

Whatever you decide, make sure it’s clearly stated and that you have the right people review and approve the policy. The example below illustrates one approach to defining who’s covered by a policy:

What’s Covered

There’s a lot of misunderstanding and disagreement about what exactly qualifies as “open source software.” One common misconception is that freeware, free to use, and free for personal use only licenses are open source software licenses.

Companies typically decide that any software released under a license approved by the Open Source Initiative (OSI) is considered open source software.

You need to define what is covered and what is not covered by your company’s open source software policy. Many companies have different standards for open source software used in IT, development, and production environments.

You’ll also need to think about what qualifies as open source software and what usage cases need to be covered.

Does the policy apply to using software inside the company?
Does it apply to shipping software?
To freeware? People often assume anything that doesn’t cost money is open source software—that’s not true, and you need to explicitly include or exclude that type of software.

An open source policy might address the issue of what qualifies as open source with language like this:

Ownership

Your open source software policy will be a living document. As business conditions change, your company becomes more comfortable using open source software, and new open source software packages and licenses become available, you’ll want to adapt the policy to the new situations. In addition, an individual or team needs to be available to answer questions, provide training, and approve any exceptions.

Although an individual usually writes the open source software policy, a committee or open source review board should own the policy. A review board is most effective when it represents the main divisions in the company. If every group feels like they’re adequately represented, you’ll get better buy-in and compliance later on.

When to Make Exceptions and Who’s Allowed to Make Them

Only a couple of people should be allowed to make exceptions to the open source software policy: the owners of the policy, and the business group or manager who’s allowed to decide that the business benefit outweighs the risk of breaking from the policy.

Approval Process

While it’s easier create an open source software policy before establishing an approval process, in reality the opposite usually occurs. Someone is responsible for making open source decisions, and he or she ends up pulling together a group of people to create an informal approval process. Once established, even informal approval processes can become quite elaborate and efficient.

If you don’t have an approval process, you’ll want to sent one up. If you have one, you’ll need to review it with your open source policy in mind.

Who’s Part of the Open Source Review Process?

You may want to establish a cross-divisional open source review board. This is usually the same team that owns the open source software policy. It should definitely include an attorney or work closely with one.

You’ll also want the review board to include any teams that will use approved open source software, as it’s important that they agree with the policy as well as the process. They can give you feedback to make sure the process integrates smoothly with their work flow so that reviews happen quickly and issues are resolved smoothly.

What Information Should Be Reviewed?

Decide what information should be included in the review process. At a minimum you’ll want each open source usage request to include:

Name of the employee submitting the request.
Name and version number of the requested open source software package.
Source of the software (website from which it was downloaded).
List of the licenses associated with the software and any bundled components.
Business reason for the request.
Platform on which the software will be installed.
Plan for integrating the open source software into other software currently being used or produced.
Whether or not there are plans to modify the source code (Y/N). If yes, explain the reason for modification.
Whether or not there are plans to distribute the open source software, either modified or not (Y/N). If yes, explain the reason for distribution.
Plan for supporting the software, monitoring for security updates, and performing upgrades.

Next, decide on the process for reviewing requests. You’ll probably save a lot of unnecessary reviews by asking local management and attorneys to review requests before they’re escalated to the corporate open source review board.

Best practices for open source approval processes include:

Ensure quick turn-around on all requests. If the approval process takes weeks, developers will skip it because they need to download open source software and get their job done. Your approval process should take one or two weeks at most.
Ensure all review board members are committed to the process. You should be prepared to replace people as the original members move onto other interests or discover they don’t have enough time anymore.
Have a really good “pre-approved open source list”. You can pre-approved by license, package name, and/or usage models.
Get lots of attorneys involved. While there may be an attorney on the review board, it will help if you have attorneys close to the team involved. They will best be able to understand how the open source software will be used, and they can help field questions. Educate these attorneys over time.
Create an exception process, but do your best to set it up in a way that minimizes the use of exceptions.
Make public within your organization all open source requests as well as the review board results. If people can see what has been requested and why certain packages were approved or denied they can tailor their requests appropriately, saving you a lot of time.
Define some standard business reasons for your organization. Depending on your open source strategy these could vary from “saving time by using existing technology” to “saving money by eliminating licensing fees” to “getting buy-in from technical adopters by enabling them to see how product is developed.”

Audits

Although your policy can require all open source software be reviewed and approved through a defined process, it’s impossible to enforce by brute force—open source software can easily and freely be downloaded from the Internet. In order to make sure your approval process is effective and that employees are following it, you’ll need to define an audit process.

The flowchart below illustrates a typical open source audit process:

Sourcing

Your policy should explicitly state the websites and methods through which employees are allowed to obtain open source software (sourcing) and how to decide whether a particular open source package is the right piece of software for the job (selection). Who can download software? Where can they go to download it? Do they need permission before downloading? Before using? Before distributing?

Many companies allow developers to download software and try it before going through the approval process. Attorneys are often uncomfortable with this because employees can use the software before the license is reviewed. However, businesses typically balance this concern with the fact that the risk is relatively small while the developer is just evaluating the software.

Most companies end up adopting a free-for-all open source download and maintenance program—every team that needs an open source software package is permitted to download it and figure out their own support options. This is highly inefficient and often leads to the situation where a company is using many different versions of the same software package as well as duplicating evaluation and upgrade processes every time a new version is released.

Other companies have adopted the idea of an open source repository in which approved open source packages are stored. Employees who need to use open source software are required to download it from the repository instead of the Internet. While an excellent idea, this approach often leads to failure because it’s difficult for a single company that’s not in the open source software business to create and maintain a comprehensive open source repository. The repository often ends up outdated and missing many useful open source software packages. If you go with this approach, you’ll need a very good process for handling requests to add new open source packages or versions to the repository. Alternatively, you can use an open source repository provided by a third-party, like OpenLogic Exchange (OLEX) from OpenLogic.

A policy that defines how and where employees can obtain open source software might look like this:

Alternatively, your policy can allow employees to make a judgment call when it comes to sourcing:

Note that while many attorneys recommend that no software be downloaded until the license is reviewed and approved, this is rarely followed. Your policy needs to take into account the legal risk of downloading software for testing or trial purposes before attorneys have a chance to review it. Adding a clause like this can help mitigate the risk:

Selection

Selection is the process of deciding whether or not a particular software package meets your needs and quality standards. In addition to any testing and standards processes already have in place, you might want to consider additional aspects for reviewing open source software such as:

Support: There are options for support for open source software, but which options are available and which you should choose may vary from package to package.
Community: Is there an active open source community for the package? Are bugs fixed quickly?
Quality: Is the software package reliable? How does it compare to similar open source packages?

For a list of other factors to consider around open source package selection, see the OpenLogic Certification Process white paper.

A policy might approach the issue of open source selection with language like this:

Your policy may also outline what to do in case an open source project “ends” or forks. For example, the policy might define a timeframe in which the team has to find a different open source package to replace the original package:

Mergers and Acquisitions

Don’t forget to include a section in your policy about mergers and acquisitions. Enterprises often fail to investigate open source usage or policy until after a target company has been acquired. It makes much more sense to check beforehand. You’ll need to make sure your company’s mergers and acquisitions team is aware of the internal open source policy as well as the need to investigate open source policy and usage at target companies prior to completing any acquisitions. Open source tools such as FOSSology, OSS Discovery, and OSS Deep Discovery can be run to identify the open source software deployed within a target organization.

A policy might approach the issue of mergers and acquisitions with language like this:

Support

Technical support in the open source world has a bad reputation. While many people think there’s no support available for open source software, the real problem is that there are too many choices for open source software support—and few of them resemble what people are used to in the proprietary world.

Options vary from do-it-yourself (by following mailing lists and even fixing critical bugs yourself) to paying a third party for a complete support and maintenance contract. The table below shows some of the common options:

Type	Mailing List	Internal	Commercial
Contact Methods	Online only	Varies	Online and phone
Resources	Other users & project developers	Your internal staff	Experts – committers and contributors
SLAs (Speed of Response)	None – could be 5 minutes to never	Maybe	Yes
Changes Accepted Into the Source Code	Sometimes	Depends – must be submitted and accepted	Typically yes
Cost	Free	Depends	Varies – per project, per server, per incident, flat fee, etc.

An open source policy might address the issue of technical support with language like this:

Maintenance

Once the decision to use open source has been made, the process of downloading it and getting it to work is often challenging and satisfying. However, it can be frustrating to track the project for security updates, solve problems, and figure out when to upgrade to a new version.

Your open source policy should provide guidance on maintenance concerns by addressing the following issues:

Security updates: Who’s going to be responsible for staying abreast of security updates? This often requires subscribing to a mailing list.
New versions: Who’s going to figure out when you should upgrade to a new version? Deciding when to upgrade can be hard because open source software projects release new versions often. While some projects are very good about specifying what’s new, what’s changed, and what’s gone, others are not. Someone will have to evaluate each release and decide whether or not to upgrade. In addition, you’ll need a process to ensure that only one or two versions (or as few as possible) are deployed within the company. In particular, you’ll want to ensure the company doesn’t fall too far behind the latest version available from the open source project, as communities rarely support previous versions for long.
Bugs: When a bug is discovered, what’s the process for reporting it to the open source project? Your policy should also specify when and how employees can fix bugs and submit bug fixes to open source projects. (You may want to provide some training about how best to create and provide patches, as it’s in your best interest to make sure patches are accepted upstream.)

The maintenance section of your open source policy should specify whether or not company employees can modify open source software. While you’ll probably want to encourage people to not modify open source software (unless they are planning on fixing a bug or adding a new feature to contribute upstream), it’s likely that some packages will require modifications to work in your environment or process. Your policy should specify when that’s allowed and how changes are documented for maintenance.

An open source policy might address the issue of ongoing maintenance with language like this:

Contributions

Your open source policy should include a clear statement about whether or not employees can contribute code changes to open source software projects. There are several situations in which you’ll probably will want employees to contribute. For example, if an employee fixes a bug, you’ll want him or her to contribute the patch to the project so that you don’t have to maintain a unique patch through every version upgrade. In addition, by contributing code your company might gain credibility within the open source community. If your company actively contributes to a project, the community will be be more likely to recognize employees and quickly respond to their emails when issues arise.

Situations to consider when thinking about whether employees can contribute code changes to open source software projects include:

Can employees post questions and answers on mailing lists? While many companies are afraid of what employees may accidentally reveal on mailing lists, it’s best to give them the proper training on confidentiality and then let them work on mailing lists. Not only will they build credibility for themselves and the company, but it’s often one of the best ways to get help with a problem. Disallowing employee contributions on mailing lists will impede employees’ ability to use and support open source software solutions.
Can employees post bug reports to the bug tracking system? Unless there are very good business reasons not to, you should allow employees to post bug reports in order to ensure they can be fixed in a timely manner that will work for the company.
Can employees fix bugs and submit their patches? Employees often need to fix simple bugs in order to get things up and running. When they do, it’s in the company’s best interest to ensure the bug is fixed in a general way that’s acceptable to the project so it can be submitted upstream. This will simplify support over the long term and help build credibility for the company.
Can employees contribute features to an open source project? Can they become project contributors?
Can employees work on open source software projects in their free time? On the same project(s) they work on in the office? On unrelated projects? How do you decide if a project is unrelated to the company’s business?

An open source policy might address the issue of open source contributions with language like this:

Some open source policies state that employees can only interact with open source communities using personal email addresses, not company email addresses. Note that if you include this rule in your open source policy, your company will never develop any credibility with the community.

Communication

Although many companies try to hide that fact that they use open source software, it rarely remains a secret—especially for organizations that decide to provide their own support using internal resources. It’s best to establish a policy for how employees should communicate with open source communities and other interested parties, even if you intend to limit communication about open source usage as much as possible.

Your open source policy should provide guidance on communication by addressing the following issues:

How can employees communicate with open source software projects? (For more on this topic, see the Maintenance section above.)
How can employees communicate about open source usage at conferences? Employees will likely want to attend open source software conferences, which provide an excellent opportunity to meet open source project maintainers. If employees can talk about which open source packages they’re using and even present case studies, it will help them meet the right people and gain credibility for your company. The open source software community likes hearing about how their products are being used.
How can employees communicate about open source usage in documentation? If you ship products that contain open source software, you may have to display the open source software licenses in the product documentation (depending on the licenses). You might also want to say something to end users about what you’re using and why, depending on the type of end users. For example, if you sell TVs that use open source software you may need to display one or more licenses in order to comply with them, but you probably don’t need to spend a lot of time talking about the software installed on the TV. If, on the other hand, you distribute a toolkit for software developers, you’ll probably want to allow more space in your documentation for discussion about the open source software you’re using and why it’s part of the toolkit.

Summary

Be sure to remain positive in the summary of your open source policy—after all, you want your employees to want to follow the policy—while also clearly stating when and how open source software usage triggers review. For example, the summary section of a corporate open source policy might look like this: