Apache HTTP Server

The Apache Software Foundation (ASF) has received a [United States District Court subpoena] requiring the production of documents related to the use of Apache Harmony code in the Android software platform, and the unsuccessful attempt by Apache to ... [More] secure an acceptable license to the Java SE Technology Compatibility Kit. The request, received from Oracle America's attorneys on May 2nd gives the Foundation until May 13th, 2011 to produce the required materials. Apache will, of course, be complying with all court requirements.  As an open development group the majority of our documents are already publicly available. Please address any discussion to the ASF Legal mailing list. # # # [Less]

Any projects in the position of being able to release via PEAR packages can now do so hosted officially on ASF servers. http://pear.apache.org is now up and running and ready to serve!

This blog was written by our new committer Vladimir Ivanov who implemented a feature that users have been wanting for a long time.  In this blog, I'll discuss how container-managed authentication works with an LDAP server and how to connect and ... [More] get additional information from it. I'll use Jetty and Apache Tomcat web servers with Apache Directory Server (ADS) 1.5.7 - a certified LDAPv3 compatible server. It is also possible to use different LDAP compatible server such as a 389 Directory Server or MS Active Directory. An LDAP server is a directory service that contains objects organized in a hierarchical manner. Apache Directory Server (ADS) The ADS project page provides a detailed server installation and configuration guide, but here are the basic steps: during the installation, the default server instance will be created. The configuration settings for this instance are defined in the server.xml file as Spring bean definitions. Below is an excerpt from the configuration file that was used for this blog. server.xml First of all, it is necessary to create a new partition: ... <partitions> ... <jdbmPartition id="lester" suffix="dc=lester,dc=org" /> </partitions> Ports that LDAP server will use are specified as tcpTransport elements: <ldapServer id="ldapServer" allowAnonymousAccess="false" saslHost="ldap.example.com" saslPrincipal="ldap/[email protected]" searchBaseDn="ou=users,ou=system" maxTimeLimit="15000" maxSizeLimit="1000"> <transports> <tcpTransport address="0.0.0.0" port="10389" nbThreads="8" backLog="50" enableSSL="false"/> <tcpTransport address="localhost" port="10636" enableSSL="true"/> </transports> </ldapServer> The local path to the directory containing LDIF files should also be specified: <apacheDS id="apacheDS"> <ldapServer>#ldapServer</ldapServer> <ldifDirectory>PATH_TO_ADS_INSTALL_DIR/instances/default/ldif</ldifDirectory> </apacheDS>  Other configuration settings were left unchanged. Now It is time to create the directory structure. I used the popular open source tool JXplorer for this task. It is possible to export the directory structure from the JXplorer tool to the LDIF file — directory content in text format. Let's review the generated file. lester.ldif Below is a record list beginning from the top. Note that each record has specific set of object classes defined in this schema. Each object class defines specific set of attributes, for example, person class defines Surname (sn) and Given Name (givenName) attributes. One object class can extend another, for example organizationalPerson class extends person class. top is a superclass for all other classes. Domain lester.org is the root of this hierarchy: dn: dc=lester,dc=org objectClass: extensibleObject objectClass: domain objectClass: top dc: lester The Organizational Unit esme is placed one level lower: dn: ou=esme,dc=lester,dc=org objectClass: organizationalUnit objectClass: top ou: esme The Organizational Unit Groups resides under the esme Organizational Unit: dn: ou=Groups,ou=esme,dc=lester,dc=org objectClass: organizationalUnit objectClass: top ou: Groups There is only one group esme-users on the lowest level of the hierarchy and it has the vivanov user (specified by a full path) as a unique member: dn: cn=esme-users,ou=Groups,ou=esme,dc=lester,dc=org objectClass: groupOfUniqueNames objectClass: top cn: esme-users ou: Groups uniqueMember: uid=vivanov,ou=Users,ou=esme,dc=lester,dc=org The Organizational Unit Users resides under the esme organizational unit: dn: ou=Users,ou=esme,dc=lester,dc=org objectClass: organizationalUnit objectClass: top ou: Users The user vivanov and its corresponding attributes are defined on the lowest level of the hierarchy: dn: uid=vivanov,ou=Users,ou=esme,dc=lester,dc=org objectClass: organizationalPerson objectClass: person objectClass: uidObject objectClass: inetOrgPerson objectClass: top cn: vivanov givenName: Vladimir mail: [email protected] ou: Users sn: Ivanov telephoneNumber: +7 111 222 33 44 uid: vivanov userPassword:: cXdlcnR5 There is also a special user with administrative rights: uid=admin,ou=system (default password: secret) defined in system schema. It was used to connect to ADS from JXplorer. Those were all basic steps necessary to configure ADS for purpose of this b log. Let's move to the configuration of the web servers. Configuration Before digging into the configuration details specific for each web server, let's review the common properties used to connect to the LDAP server. First of all, it is necessary to specify the hostname / ip address and the port of our LDAP server — localhost:10389, as well as the credentials for an account that has rights to perform search operation and get attributes for users and roles in a directory tree. The special admin user described in previous section was also used for this purpose in this blog. Sometimes anonymous access is also permitted. The next set of properties, user base and group base, specify the base context with which to lookup users and groups. For our configuration web server will search users under ou=Users,ou=esme,dc=lester,dc=org and groups under ou=Groups,ou=esme,dc=lester,dc=org paths in the directory tree accordingly. The user id and role name attributes specify the prefix for user/group search filter. In our example, it has the uid value for users and the cn value for groups. The uniqueMember attribute is used to check whether the user belongs to the specified group. Now it is time to review the configuration for each of the web servers. Note: The required lift-ldap dependency has been already included in pom.xml. Jetty In order to configure Jetty to use LDAP server, two additional Maven dependencies: jetty-plus and jetty-ldap-jaas should be added to the pom.xml file. Configuration of maven-jetty-plugin includes the following steps: set the JAASUserRealm as an user realm implementation and specify the ldaploginmodule as the login module name. It is also necessary to set the system property java.security.auth.login.config with the ldap-loginModule.conf value: pom.xml <dependency> <groupId>org.mortbay.jetty</groupId> <artifactId>jetty-plus</artifactId> <version>[6.1.6,)</version> <scope>compile</scope> </dependency> <dependency> <groupId>org.mortbay.jetty</groupId> <artifactId>jetty-ldap-jaas</artifactId> <version>[6.1.6,)</version> <scope>compile</scope> </dependency> <plugin> <groupId>org.mortbay.jetty</groupId> <artifactId>maven-jetty-plugin</artifactId> <configuration> <contextPath>/</contextPath> <scanIntervalSeconds>0</scanIntervalSeconds> <userRealms> <userRealm implementation="org.mortbay.jetty.plus.jaas.JAASUserRealm"> <name>ESMERealm</name> <loginModuleName>ldaploginmodule</loginModuleName> </userRealm> </userRealms> <systemProperties> <systemProperty> <name>java.security.auth.login.config</name> <value>ldap-loginModule.conf</value> </systemProperty> </systemProperties> </configuration> </plugin> The file ldap-loginModule.conf is placed under the ESME_ROOT/server folder. It specifies login module implementation class - LdapLoginModule as well as LDAP-specific connection properties: ldap-loginModule.conf ldaploginmodule { org.mortbay.jetty.plus.jaas.ldap.LdapLoginModule required debug="true" useLdaps="false" contextFactory="com.sun.jndi.ldap.LdapCtxFactory" hostname="localhost" port="10389" bindDn="uid=admin,ou=system" bindPassword="secret" authenticationMethod="simple" forceBindingLogin="false" userBaseDn="ou=Users,ou=esme,dc=lester,dc=org" userRdnAttribute="uid" userIdAttribute="uid" userPasswordAttribute="userPassword" userObjectClass="inetOrgPerson" roleBaseDn="ou=Groups,ou=esme,dc=lester,dc=org" roleNameAttribute="cn" roleMemberAttribute="uniqueMember" roleObjectClass="groupOfUniqueNames"; }; Note that for some environments forceBindingLogin attribute must also be set to true. Tomcat The only required change in the Tomcat's server.xml configuration file (compared to the changes described in the last blog) is a different realm - JNDIRealm. This realm is used to connect to LDAP server and search users/groups: server.xml ... <Realm className="org.apache.catalina.realm.JNDIRealm" connectionName="uid=admin,ou=system" connectionPassword="secret" connectionURL="ldap://localhost:10389" debug="99" referrals="follow" roleBase="ou=Groups,ou=esme,dc=lester,dc=org" roleName="cn" roleSearch="(uniqueMember={0})" roleSubtree="true" userBase="ou=Users,ou=esme,dc=lester,dc=org" userSearch="(uid={0})" userSubtree="true"/> … LDAPVendor and ESMELdap.properties file The web server is now configured to perform CMA. But the Servlet API makes only the user principal available for application. In order to fill ESME user's profile, additional attributes such as firstname, lastname and email are needed. We will use LDAP server to retrieve these attributes. Let's review changes in UserAuth.scala, specifically in ContainerManagedAuthModule object: UserAuth.scala To connect to the LDAP server from application first of all, it is necessary to create aq subclass of net.lift.ldap.LDAPVendor class: object myLdapVendor extends LDAPVendor All LDAP-specific connection properties are placed into a resource bundle — plaintext property file with key-value pairs. It is possible to get property values by key with the S.? method: def myLdap : LDAPVendor = { val ldapSrvHost = S.?("ldap.server.host") val ldapSrvPort = S.?("ldap.server.port") val ldapSrvBase = S.?("ldap.server.base") val ldapSrvUsrName = S.?("ldap.server.userName") val ldapSrvPwd = S.?("ldap.server.password") val ldapSrvAuthType = S.?("ldap.server.authType") val ldapSrvReferral= S.?("ldap.server.referral") val ldapSrvCtxFactory = S.?("ldap.server.initial_context_factory") The next step is to configure the LDAPVendor subclass with these values: myLdapVendor.configure(Map("ldap.url" -> "ldap://%s:%s".format(ldapSrvHost, ldapSrvPort), "ldap.base" -> ldapSrvBase, "ldap.userName" -> ldapSrvUsrName, "ldap.password" -> ldapSrvPwd, "ldap.authType" -> ldapSrvAuthType, "referral" -> ldapSrvReferral, "ldap.initial_context_factory" -> ldapSrvCtxFactory)) myLdapVendor } The method getAttrs takes the username as a parameter and returns a map of [attribute name / list of attribute values] pairs (attribute in LDAP might contain more than one value) for this user. Let's review the method definition. It is possible to get attributes for user with LDAPVendor.attributesFromDn() method. It takes the distinguished name as a parameter, so it is necessary to append the prefix and the user base from the property file to the username to construct it. Note that the attributesFromDn method returns javax.naming.directory.Attributes therefore the interfaces from javax.naming.directory package must be imported correctly: import _root_.javax.naming.directory.{Attributes, Attribute => Attr} The shorthand Attr is used for the javax.naming.directory.Attribute because the scala.xml.Attribute trait has already been imported and placed in scope. Then attribute's id and values are used to populate the result map. The getAttrs method definition is shown below: def getAttrs(who : String) : Map[String, List[String]] = { val uidPrefix = S.?("ldap.uidPrefix") val userBase = S.?("ldap.userBase") var attrsMap = Map.empty[String, List[String]] val dn = "%s=%s,%s".format(uidPrefix, who, userBase) val attrs : Attributes = myLdap.attributesFromDn(dn) if (attrs != null) { val allAttrs = attrs.getAll(); if (allAttrs != null) { while(allAttrs.hasMore()) { val attribute = allAttrs.next().asInstanceOf[Attr]; var attrValues = List.empty[String] for(i <- 0 until attribute.size()) { attrValues ::= attribute.get(i).toString } attrsMap += (attribute.getID() -> attrValues) } } } attrsMap } The last step is to modify the performInit method. First of all, it is necessary to check if LDAP is enabled as configured in the property file. Then the values for attributes givenName, sn and mail are extracted from the map, returned via the getAttrs method call and then used to populate User instance. def performInit(): Unit = { ... val usr = User.createAndPopulate.nickname(username).saveMe //find and save additional attributes in LDAP if It is enabled val ldapEnabled = S.?("ldap.enabled") if(ldapEnabled.toBoolean) { val ldapAttrs = getAttrs(username) val firstName = ldapAttrs("givenName").head val lastName = ldapAttrs("sn").head val mail = ldapAttrs("mail").head usr.firstName(firstName).lastName(lastName).save } ... } The ESMELdap property file is shown below. It essentially resembles connection properties in web server configuration files that we have seen previously. ESMELdap.properties file #This flag specifies whether LDAP should be used ldap.enabled=true # Hostname or IP of LDAP server ldap.server.host=localhost # Port of LDAP server ldap.server.port=10389 # Base DN from the LDAP Server ldap.server.base=ou=esme,dc=lester,dc=org # User that has access to LDAP server to perform search operations ldap.server.userName=uid=admin,ou=system # Password for user above ldap.server.password=secret # Authentication type ldap.server.authType=simple # Referral ldap.server.referral=follow # Initial context factory class ldap.server.initial_context_factory=com.sun.jndi.ldap.LdapCtxFactory # Prefix for user to whom additional LDAP attributes belong, for example 'uid' or 'sAMAccountName' ldap.cnPrefix=uid # User base DN for user to whom additional LDAP attributes belong ldap.userBase=ou=Users,ou=esme,dc=lester,dc=org The last thing that must be done is to tell Lift where to look for the ESMELdap.properties file. The list of resource file names is assigned to LiftRules.resourceNames var in Boot.scala: Boot.scala LiftRules.resourceNames = "ESMELdap" :: "ESMECustom" :: "ESMEBase" :: "ESMEUI" :: Nil Conclusion We have just configured both web servers - Jetty and Tomcat - to perform authentication and authorization via LDAP. We have also improved ContainerManagedAuthModule to get additional attributes for authenticated user from LDAP with Lift LDAP API. Links 1. Apache Directory Server: http://directory.apache.org/apacheds/1.5/ 2. Jxplorer: http://jxplorer.org/ 3. Jetty login modules: http://docs.codehaus.org/display/JETTY/JAAS http://jetty.codehaus.org/jetty/jetty-6/apidocs/org/mortbay/jetty/plus/jaas/ldap/LdapLoginModule.html 4. Tomcat user realms: http://tomcat.apache.org/tomcat-6.0-doc/realm-howto.html 5. Lift API: http://scala-tools.org/mvnsites/liftweb-2.3/ [Less]

Second annual Get-Together. No fees no conference and no sessions. Just an excuse to get-together, code, and have a beer or two. Hacking Monday - Thursday. Friday and the weekend is for non-technical fun. Tech-time will likely be focusing on ... [More] TomEE, Java EE 6 Web Profile and OSGi hacking. If you have something you've been wanting to work on, come on down and I'm sure someone will be available to give you some pointers and get you rolling. Even if you just know you want to work on something but don't know what, I'm sure we can find a nice little project for you. Even the smallest task has a way of taking you in unexpected and fun directions. Most of us are staying here: http://www.hotel-ronsard.com A good second choice: http://www.hoteldeschateaux.fr Jean-Louis' company, Atos Origin, has graciously offered space for daytime hacking fun. Please rsvp to him if you wish to partake as he will need to get you a security badge. His apache address is jlmonteiro@. I've heard rumors of a limited supply of food and coffee on the premises for those that rsvp. So definitely get word to JL! Evening fun will likely be around the center of Tours. I'll try and twitter our locations, facebook checkin and am happy to give out my cell and google voice to anyone who would love to happen by for a beer. Just email me offline. There are likely some neat social networking tools we could use, feel free to suggest one. Hope to see you there! [Less]

Join us next week at JAX London 2011 where David Blevins and Jonathan Gallimore will be presenting two presentations on EJB and Java EE. Fun with EJB 3.1 and OpenEJB Tuesday, April 12th Apache TomEE: Tomcat with a Kick Wednesday, April 13th ... [More] Both sessions will be demo heavy and hands on. See some of the neat innovations happening in the OpenEJB 4.0 codebase such as meta annotations. Get an demo and introduction to the new Apache TomEE platform a Tomcat-focused Java EE 6 Web Profile implementation assembled in minimalist fashion from all-Apache projects. And of course, a good chance to talk with the developers and ask all the questions you want! You won't want to miss it! [Less]

Part 1: Performing authentication with plaintext/xml user-role mapping This blog was written by our new committer Vladimir Ivanov who implemented a feature that users have been wanting for a long time.  ... [More] Introduction Apache ESME currently supports two different authentication schemes: when user credentials are stored in the database and via OpenID.  Corporate users, however, might be interested in container-managed authentication (CMA) — because this scheme supports integration with enterprise services such as LDAP and Single Sign-On. In the first part of this blog,  I'll explain how ESME-based applications can use CMA and how to configure two popular web servers- Apache Tomcat and Jetty - with simple user-role mapping. In the second part, I'll describe LDAP integration to perform CMA and how get additional user attributes via the Lift LDAP API. ContainerManagedAuthModule: The necessary code changes A new authentication module ContainerManagedAuthModule was introduced to hook into the container-managed authentication process. First of all, it was registered along with the other authentication modules: Boot.scala     UserAuth.register(UserPwdAuthModule)     UserAuth.register(OpenIDAuthModule)      UserAuth.register(ContainerManagedAuthModule) UserAuth.scala All authentication modules should extend the AuthModule trait: object ContainerManagedAuthModule extends AuthModule Currently, the list with security role (group) names is also defined in the source code:   val rolesToCheck = List(     "esme-users"   ) It is also possible to get the list of roles from some external source, for example, from a property file or a LDAP. The method moduleName defines the name for the new auth module. This value acts as a discriminator and will be stored in the DB:   def moduleName: String = "cm" After the container finishes the authentication and authorization phases, it is  neccessary to hook into the normal user processing to save the user data. This task is performed in the performInit method: def performInit(): Unit = { CMA must be applied to a specific URL, for example /cm/login, so it is necessary to append a partial function to LiftRules.dispatch to perform the neccessary operations:     LiftRules.dispatch.append {       case Req("cm" :: "login" :: Nil, _, _) =>  {         val from = "/" Note: The majority of necessary steps to further utilize this new auth method have already been desribed in the Lift Wiki. In short, it is neccessary to unwrap the javax.servlet.http.HttpServletRequest object to get the username and role names. If a user has one of the specified roles, the module should attempt to find an existing user with the same nickname which previously has logged in via this module. If such a user hasn't been found, a new User is created.  The last step is to save the userId in the HTTP session via User.logUserIn method call.         S.request match {           case Full(req) => {             val httpRequest: HTTPRequest = req.request             val hrs = httpRequest.asInstanceOf[HTTPRequestServlet]             val hsr: HttpServletRequest = hrs.req             val username : String = hsr.getRemoteUser             if(username!=null){               val currentRoles = rolesToCheck.filter(hsr.isUserInRole(_))               if(currentRoles.size == 0) {                 info("No roles have been found")                 S.error(S.?("base_user_err_unknown_creds"))               } else {                 currentRoles.map(cr => {                 (for {                     user <- UserAuth.find(By(UserAuth.authKey, username),                                           By(UserAuth.authType, moduleName)).flatMap(_.user.obj) or                     User.find(By(User.nickname, username))                   } yield user) match {                     case Full(user) => {                       logInUser(user)                     }                     case _ => {                       val usr = User.createAndPopulate.nickname(username).saveMe                       //find and save additional attributes in LDAP if it's enabled               ...                       }                       UserAuth.create.authType(moduleName).user(usr).authKey(username).save                       logInUser(usr)                     }                   }                 })               }     } Configuration Now it's time to set-up the configuration for the CMA. All configuration settings for a Java EE web application (ESME is based on the Lift web framework, so it's packaged as a WAR file), including security settings, are defined in the web.xml file: web.xml For this example, we will use form-based authentication: <login-config>       <auth-method>FORM</auth-method>       <realm-name>ESMERealm</realm-name> Next, the login and error pages are specified.         <form-login-config>             <form-login-page>/cm_login.jsp</form-login-page>             <form-error-page>/cm_error.jsp</form-error-page>         </form-login-config>     </login-config> Then, the security-role name, which any authenticated user must have for successful authorization, is defined:     <!-- Security roles referenced by this web application -->     <security-role>       <description>An authenticated ESME user</description>       <role-name>esme-users</role-name>     </security-role> And finally it is necessary to configure the mapping between the security role and the URL which is associated with the new authentication module:   <!-- Secured resources -->     <security-constraint>       <web-resource-collection>         <web-resource-name>ForceLogin</web-resource-name>         <description>Secured page for forcing the container to request login</description>         <url-pattern>/cm/login</url-pattern>       </web-resource-collection>       <auth-constraint>         <role-name>esme-users</role-name>       </auth-constraint>     </security-constraint> The login page contains a form with specific action attributes and two input fields: cm_login.jsp <html>     <head>       <title>Login</title>     </head>     <body id="cm_login">         <form method="POST" action="j_security_check">           Username: <input type="text" name="j_username"/><br>           Password: <input type="password" name="j_password"/><br>           <input type="submit"/>         </form>     </body> </html> Let's move on to the web server configuration for the next steps. We must define the users for our web application as well as mapping between these users and the security role that is specified in the web.xml file. I'll show how to configure simple user-role mapping for two popular web servers — Jetty and Tomcat. Jetty The HashUserRealm implementation is used to specify the user-role mapping in the properties file for Jetty. The maven-jetty-plugin has been already included in the Maven project file pom.xml for the ESME application, so it is possible to configure Jetty in the plugin configuration section: pom.xml             <plugin>                 <groupId>org.mortbay.jetty</groupId>                 <artifactId>maven-jetty-plugin</artifactId>                 <configuration>                     <contextPath>/</contextPath>                     <scanIntervalSeconds>0</scanIntervalSeconds>                     <userRealms>                         <userRealm implementation="org.mortbay.jetty.security.HashUserRealm">                             <name>ESMERealm</name>                             <config>jetty-login.properties</config>                         </userRealm>                     </userRealms>                 </configuration>             </plugin> The format for this property file has the following form: username: password [,rolename ...]. An example is shown below: jetty-login.properties cmuser: cmuser, esme-users That's it. Now Jetty is configured for CMA. Execute mvn clean jetty-run command to start Jetty and type http://localhost:8080/cm/login URL in your browser. You should see the form containing the username and password fields. Now try to log in with the user with the id cmuser. Tomcat The configuration of Tomcat web server is very similar to that of Jetty, except that the user-role mapping is specified in a XML file.  The MemoryUserDatabaseFactory implementation is used to define the mapping file.  The corresponding realm UserDatabaseRealm is also specified in the server.xml configuration file: server.xml   <GlobalNamingResources>     <!-- Editable user database that can also be used by          UserDatabaseRealm to authenticate users     -->     <Resource name="UserDatabase" auth="Container"               type="org.apache.catalina.UserDatabase"               description="User database that can be updated and saved"               factory="org.apache.catalina.users.MemoryUserDatabaseFactory"               pathname="conf/tomcat-users.xml" />   </GlobalNamingResources> ...       <Realm className="org.apache.catalina.realm.UserDatabaseRealm"              resourceName="UserDatabase"/> Below is an example of the user-role mapping definition in the tomcat-users.xml file which is usually located in the  tomcat/conf directory. tomcat-users.xml <tomcat-users>   <role rolename="esme-users"/>   <user name="cmuser" password="cmuser" roles="esme-users"/> </tomcat-users> Now it's neccessary to package the WAR file with the mvn clean package command and deploy it to Tomcat either via maven plugin or in Tomcat's administrative console. Then proceed to the following URL: http://localhost:8080/your_web_context/cm/login The login form should be displayed. Conclusion In this part of the blog, I've covered the new authentication module, application and server configuration and simple user-role mapping. In the next part, I'll show how to configure Tomcat to use LDAP for CMA and get additional attributes for the authenticated user. Links 1. Lift Wiki - How to use Container Managed Security : http://www.assembla.com/wiki/show/liftweb/How_to_use_Container_Managed_Security 2. Jetty HashUserRealm: http://jetty.codehaus.org/jetty/jetty-6/apidocs/org/mortbay/jetty/security/HashUserRealm.html 3. Tomcat Realms: http://tomcat.apache.org/tomcat-6.0-doc/realm-howto.html 4. Java EE 5 Tutorial – Securing Web Applications: http://download.oracle.com/javaee/5/tutorial/doc/bncas.html [Less]

Apache Click 2.3.0 final is available for download. v2.3.0 contains important new features including Ajax support, Page Actions and light-weight stateful controls. In addition there are new documentation, examples and a slew of other enhancements. ... [More] Click Home Roadmap and Changes - full list of new features, improvements and bug fixes Upgrade Path - please see the upgrade path when upgrading from 2.2.0 or earlier. Download Click 2.3.0 Maven bundles Live examples New features and improvement: Ajax support. Page Action support. Stateful Controls. Improve fields to only be processed if they have an incoming request parameter. This improvement streamlines dynamic forms since fields added at runtime during s POST request won't bind their values and won't be validated for that request. In subsequent requests the Field will have an incoming parameter and so will have it's value bound and validated. Another advantage is that dynamically added Fields won't have their default value overridden in the POST request they were added in. This issue has been raised by Nirmal Solanki [CLK-722]. Added automapping support for GAE with a caveat that page templates must be placed under the folders page or pages. This issue was raised by Ke Sun [CLK-639]. Added MessagesMapService interface to support pluggable messages map implementations [CLK-655]. Improved MessagesMap to be extendable and customizable [CLK-728]. Added support for loading DateField translations for month and day names from the JDK. [CLK-650]. Added support for Menus that do not have roles defined. If no roles are defined, IsUserInRoles passes a null argument to hasAccess to determine whether access is permitted to menus without roles [CLK-724].    Added support for multiple TabbedPanels on a page. To programmatically activate a specific TabbedPanel use the tabPanelIndex- request parameter, for example tabPanelIndex-myTabbedPanel [CLK-753]. New documentation: Added a section covering the new Behavior support. Added a chapter on Ajax, covering AjaxBehaviors, Ajax execution flow and a full example. Added a section covering the new Page Action support. New examples: Added examples showcasing the new Ajax support. See the Ajax Menu for the full list of examples. Added an example showing how to integrate a TabbedPanel, Form and Table. Added an example showing a Stateful TabbedPanel. Added an example FieldSeparator Control and example usage page [CLK-544].  Removed: Removed the ability to automatically bypass validation for Forms through JavaScript. This ability was added in 2.2.0 but raised concerns over security and was dropped for 2.3.0. If you used this feature in existing applications, please see the Upgrade path for a safe alternative to bypass validation. We apologize for the inconvenience. Deprecated: Deprecated stateful page support: Page.setStateful(). Stateful pages had the following issues: Stateful pages was introduced to make it easier to store page state across multiple HTTP requests. However developing a stateful page is very different from developing a stateless one and this lead to Click applications that are inconsistent and harder to maintain. In addition stateful page support has never been implemented consistently across the framework and some components did not work correctly. Stateful pages are very coarse grained, making it difficult to control which objects are stored in the session. Stateful pages have also introduced unnecessary complexity in the framework itself, which can now be phased out. Unfortunately there is no direct upgrade path from a stateful page. However the majority of use cases are catered for by the new stateful support in the controls: Table, Form, TabbedPanel, Field and AbstractLink. The Apache Click team [Less]

Congratulations to the Apache Hadoop Project for winning the top prize at the 2011 MediaGuardian Innovation Awards in London! Beating out nominess such as the iPad and WikiLeaks, judges of the fourth annual Media Guardian Innovation Awards (Megas) ... [More] considered Apache Hadoop a "Swiss Army knife of the 21st Century" and a greater catalyst for innovation by "having the potential to completely change the face of media innovations across the globe." ASF Chairman and original Hadoop creator Doug Cutting said, "it's great to see the continued recogntition for the technology and I am happy to accept the MediaGuardian Innovator of the Year award on behalf of this flourishing Apache community." Kudos to all involved with the Apache Hadoop Project! For more information on Apache Hadoop, visit http://hadoop.apache.org/ For more infomration on the Megas, please see http://www.guardian.co.uk/megas # # # [Less]

Well, some are not exactly new faces, but since our last blog update of new infra members in 2009 , we have conned with promises of fame, fortune and beer the following new additions to the infra team: Chris Rhodes: (arreyder) ... [More] Brian Fox: (brianf) Matt Benson: (mbenson) David Blevins: (dblevins) Rudiger Pluem: (rpluem) Noirin Plunkett: (noirin) Ulrich Stärk: (uli) Daniel Shahaf: (danielsh) Paul Davis: (davisp) Infra work is not your normal volunteer work, and it is greatly appreciated when any of these folks get to help. [Less]

Take advantage of our super-discounted, "Trust Us" rate of just US$900 for the full 3-day conference by registering before 20 May 2011. Sign up today and save 45%! For registration and pricing details, please visit http://apachecon.com/ Love ... [More] Apache? Are you an Open Source Enterprise Solutions, Cloud Computing, and Community Leadership expert? Submit a presentation proposal for ApacheCon! Our CFP closes on 29 April. We look forward to seeing you in Vancouver! [Less]