Agorava core version 0.6.1 just hit Maven Central today, it corrected some issues in 0.6.0 and added interesting features.

Release notes

Bug

• [AGOVA-33] – NPE when no OAuthSession producer is found
• [AGOVA-34] – Unserializable exception for OAuthSession on Wildfly 8.0

Enhancement

• [AGOVA-35] – Add Weld 2.0 Test profiles
• [AGOVA-39] – Adopt JBoss Community code formating
• [AGOVA-45] – Switch to a BOM model
• [AGOVA-46] – Officially switch to git flow maven plugin for release

Feature Request

• [AGOVA-36] – No more resetConnection() in 0.6.0
• [AGOVA-37] – Add a Servlet to manage callback in OAuth Dance

What does it mean in plain english? Let’s see.

CDI 1.1 and Weld 2.x support

A big thanks to Aslak Knustsen on this point. He added profiles to launch test with Weld 2.x and correxted some issue with Agorava CDI extension preventing it to run under CDI 1.1.
Agorava now support OpenWebBeans 1.1.7 and Weld from 1.1.5 to 2.0.2. We’ll continue to extends CDI support in next release especially with OpenWebBeans 2.x when it’ll be ready.

Servlet to manage callback in OAuth initialization

An old feature request was achieved in this release the callback servlet that deal with the end of OAuth initialization process. Its default behavior is to close the current window (working for a popup) but you can easily override it to add your behavior.

Dependency Management with maven BOM

Dependencies are now managed by a Maven Bill Of Material, it will allow Agorava users to integrate Agorava dependencies more easily than with a parent pom. You’ll just have to add this to the `dependencyManagement` section of your project :

    <dependencyManagement>
        <dependencies>
            <dependency>
                <groupId>org.agorava</groupId>
                <artifactId>agorava-bom</artifactId>
                <version>0.6.1</version>
                <type>pom</type>
                <scope>import</scope>
            </dependency>
        </dependencies>
    </dependencyManagement> 

thanks

Again, many thanks to Aslak Knutsen for his help and to George Gastaldi for his feedback and work on PicketLink integration.

What’s next ?

Version 0.7.0 has started (for real this time), we’re going to integrate our own OAuth engine to prepare migration to OAuth client framework and add support to Apache Camel to provide better integration solution (especially for Social Media providing Streaming API).
In the meantime go for :

  <dependency>
      <groupId>org.agorava</groupId>
      <artifactId>agorava-core-impl-cdi</artifactId>
      <version>0.6.1</version>
  </dependency>

check our Getting Started guide and give us your feedback

Agorava core version 0.6.0 just hit Maven Central, even if the release notes are quite short, there are a lot of big improvement in this release.

Release notes

First things first, here are the release notes.

Bug

• [AGOVA-29] – Tests fail with OpenWebBeans

Enhancement

• [AGOVA-23] – Get Rid of JBoss Logging
• [AGOVA-30] – Agorava OAuth 2.0 support doesn't follow rfc6749 (was Agorava doesn't support Empire Avenue)
• [AGOVA-31] – Removing Generics to ease control of the framework

Quite terse isn’t it? Let’s focus on main points

Stop using JBoss Solder Generics: a long story

To ease creation of new modules and end user’s application configuration, Agorava integrated from the beginning a solution to automatically create some generics beans. This solution was based on JBoss Solder Generic Beans extension. As you may know, Solder development was discontinued to be integrated in Apache Deltaspike. I tried 3 times to have this Solder functionality integrated to Deltaspike, but hadn’t enough time and energy to convince Deltaspike tech leader that it could benefit to other CDI framework development projects.
The problem was that Agorava was using Generics and that it was no more supported. First decision was to get this code from Solder and put it in an Agorava module. So we created Agorava-Utils (thanks to Ove Ranheim). In Agorava utils we put our own version of Solder Generics,but there were still issues with this solution, the main one being that Generics in Solder only worked with Weld.
So for his release, we decided to drop Generics and write our own extension system to automatically generate certain beans for each social media. Consequences of this redesign are a lighter code base to main and more important OpenWebBeans compatibility.

OpenWebBeans support

We added profile to test our code code against Apache OpenWebBeans 1.1.7+ (version used in Apache TomEE 1.5.1) and made sure that Socializer:https://github.com/agorava/agorava-socializer (our demo application) perfomed well under TomEE.
Off course Agorava still supports JBoss Weld 1.1.5+ (version present in JBoss AS 7.1.1).
So now Agorava works on the 2 main CDI implementations.

So long Solder, Hello Deltaspike

Leaving JBoss Solder include leaving JBoss Logging. We now use JUL as logging to continue reducing framework’s dependencies. Our new engine that replace Solder, makes use of Apache Deltaspike utility to register new beans when framework gets initialized. If you are interested to see how we use them, pay a visit to AgoravaExtension. I’ll probably write an article on this extension system.

Modules simultaneous release

For the first time, we also release simultaneously, Facebook, LinkedIn and Twitter module to 0.6.0 version. These release are there to provide modules supporting the new 0.6.0 API.

A fresh documentation

Finally, we updated the getting started guide to add the simplification we introduced with this release. Other documentation will be deliver in the coming week, so stay tuned.

What’s next ?

Version 0.7.0 has started, we’re going to integrate our own OAuth engine to prepare migration to OAuth client framework and add support to Apache Camel to provide better integration solution (especially for Social Media providing Streaming API).
In the meantime go for :

  <dependency>
      <groupId>org.agorava</groupId>
      <artifactId>agorava-core-impl-cdi</artifactId>
      <version>0.6.0</version>
  </dependency>

and give us your feedback

Version 0.5.2 just hit Maven Central, what’s new in this release and what to expect in the coming months

It’s been a long time

We didn’t have much time lately to work on Agorava Core but that’s going to change in the coming month.
On the module side, some initiative were started (among them stackoverflow, github, instagram…). We’ll post about them later.

Release notes

Since we didn’t gave an announcement for 0.5.X releases, you’ll find bellow a compilation of both release notes

Release Notes – Agorava – Version 0.5.1 and 0.5.2

Bug

• [AGOVA-25] – Weld 1.1.9 and beyond not supported
• [AGOVA-14] – SimpleOAuthAppSettingsBuilder doesn't work when callback url is an SSL uri
• [AGOVA-19] – Agora dependencies in dependency management uses dynamic project version

Enhancement

• [AGOVA-26] – Add OpenWebBeans tests
• [AGOVA-15] – Complicated to use Agorava without session scope
• [AGOVA-16] – Annotation @OAuthApplication make params mandatory
• [AGOVA-17] – Making PropertyOAuthAppSettingsBuilder as default builder for OAuthApplication

Task

• [AGOVA-27] – Align Generics on solder last updates

What’s coming next in core ?

We’re now actively working on API simplification and OpenWebBeans support in core. After that we’ll be working by integrating our own OAuth engine and provide a JAX-RS implementation of it. You can follow the roadmap on our Jira instance

What’s coming next in modules ?

Our main modules (Twitter, Facebook, LinkedIn) are still in snapshot. We expect to release them during Q3 2013. Stay tuned and thanks for your patience

In Agorava framework we want to provide an easy way to launch our example applications. One of the easiest way is to provide a maven Goal that build the project and launch it with embedded Jetty servlet container. If you have read our previous post you already know that right now Agorava has only a CDI implementation. So when we created Socializer demo app we add to find a way to launch CDI container from Jetty Maven Plugin. This article is about how we did it.

Launching CDI from Servlet Api

The first problem to deal with is about launching CDI container from Servlet API. CDI is a Java EE 6 specification and thus comes in all Java EE container like JBoss, TomEE or Glassfish. However the specification doesn’t provide a standard way to launch CDI container outside Java EE. Each implementation brings its own solution (to be more precise OpenWebBeans and Weld bring a solution, Candi has no known way to be launch outside Resin). We decided to go with Weld because it’s the CDI RI and that it is the implementation on which Agorava was the more tested thru Glassfish and JBoss.

Adding maven dependecies

As we want to support Jetty but also full Java EE containers we added a profile in the pom.xml to keep the Java EE build clean. As this profile is supposed to build and run the project we call it run. We add the following dependencies in the pom.xml

<profile>
  <id>run</id>
    <dependencies>
        <dependency>
            <groupId>org.jboss.weld.servlet</groupId>
            <artifactId>weld-servlet</artifactId>
            <version>1.1.8.Final</version>
            <scope>runtime</scope>
        </dependency>
        <dependency>
            <groupId>com.sun.faces</groupId>
            <artifactId>jsf-api</artifactId>
            <version>2.1.3</version>
        </dependency>
        <dependency>
            <groupId>com.sun.faces</groupId>
            <artifactId>jsf-impl</artifactId>
            <version>2.1.3</version>
        </dependency>
    </dependencies>
</profile>

Jsf dependencies are added because Socializer uses JSF and Jetty doesn’t provide thrm. The Jboss Weld Servlet is the important dependency here since it will provide bootstrapping for CDI thru servlet API. It also will bring transitively all the needed dependencies for Weld core and CDI API.

Adding Jetty Maven plugin

Now we can add the plugin to our new profile

<build>
    <plugins>
       <plugin>
          <groupId>org.mortbay.jetty</groupId>
          <artifactId>jetty-maven-plugin</artifactId>
          <version>8.1.3.v20120416</version>
       </plugin>
    </plugins>
</build>

This plugin allows to build a Maven project and launch Jetty directly from Maven with a simple mvn jetty:run command.

Boostraping CDI

To bootstrap CDI, we have 2 steps to perform :

Expose CDI bean manager thru JNDI

To do that we create a jetty-env.xml file in WEB-INF containing this

<!DOCTYPE Configure PUBLIC "-//Mort Bay Consulting//DTD Configure//EN" "http://www.eclipse.org/jetty/configure.dtd">
<Configure id="webAppCtx" class="org.eclipse.jetty.webapp.WebAppContext">
    <New id="BeanManager" class="org.eclipse.jetty.plus.jndi.Resource">
        <Arg>
            <Ref id="webAppCtx"/>
        </Arg>
        <Arg>BeanManager</Arg>
        <Arg>
            <New class="javax.naming.Reference">
                <Arg>javax.enterprise.inject.spi.BeanManager</Arg>
                <Arg>org.jboss.weld.resources.ManagerObjectFactory</Arg>
                <Arg/>
            </New>
        </Arg>
    </New>
</Configure>

This file is a standard Jetty config file and is run by the container at boot time.

Adding Web.xml configuration

To achieve the bootstrapping we also need to add two entries to web.xml :

• One to retrieve the BeanManager exposed in the file above and expose it to servlet API
• One to launch the servlet listener that will boot CDI container

As we don’t want to pollute existing web.xml which works perfectly for Java EE 6 containers, we add a web.xml overriding file to add our entries. This file is declared in Jetty plugin configuration like this

<plugin>
    <groupId>org.mortbay.jetty</groupId>
    <artifactId>jetty-maven-plugin</artifactId>
    <version>8.1.3.v20120416</version>
    <configuration>
        <webApp>
            <overrideDescriptor>src/main/webapp/WEB-INF/web-add.xml</overrideDescriptor>
        </webApp>
    </configuration>
</plugin>

The content of web-add.xml file is as follow

<web-app version="3.0" xmlns="http://java.sun.com/xml/ns/javaee" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
         xsi:schemaLocation="http://java.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/javaee/web-app_3_0.xsd">

    <listener>
        <listener-class>org.jboss.weld.environment.servlet.Listener</listener-class>
    </listener>

    <resource-env-ref>
        <resource-env-ref-name>BeanManager</resource-env-ref-name>
        <resource-env-ref-type>
            javax.enterprise.inject.spi.BeanManager
        </resource-env-ref-type>
    </resource-env-ref>
</web-app>

It’s content will override web.xml one (i.e web.xml will be interpreted before web-add.xml).

Last trick to allow injection in servlets

Weld Servlet will try to decorate some Jetty internal class to add the possibility of using @Inject inside servlets. This class is a Jetty system class and therefore is not visible from the web application. We have to tell Jetty classloader to expose this class to the web app in order to have Weld Servlet decorating it.
To allow this we create a jetty-context.xml file in WEB-INF

<!DOCTYPE Configure PUBLIC "-//Jetty//Configure//EN" "http://www.eclipse.org/jetty/configure.dtd">
<Configure class="org.eclipse.jetty.webapp.WebAppContext">
    <Set name="serverClasses">
        <Array type="java.lang.String">
            <Item>-org.eclipse.jetty.servlet.ServletContextHandler.Decorator</Item>
        </Array>
    </Set>
</Configure>

Then we add it to Jetty Maven plugin configuration like this

<configuration>
    <webApp>
        <overrideDescriptor>src/main/webapp/WEB-INF/web-add.xml</overrideDescriptor>
    </webApp>
    <contextXml>src/main/webapp/WEB-INF/jetty-context.xml</contextXml>
</configuration>

Then we’re done

To sum up

Here is the complete run Profile in our pom.xml file

<profile>
    <id>run</id>
    <dependencies>
        <dependency>
            <groupId>org.jboss.weld.servlet</groupId>
            <artifactId>weld-servlet</artifactId>
            <version>1.1.8.Final</version>
            <scope>runtime</scope>
        </dependency>
        <dependency>
            <groupId>com.sun.faces</groupId>
            <artifactId>jsf-api</artifactId>
            <version>2.1.3</version>
        </dependency>
        <dependency>
            <groupId>com.sun.faces</groupId>
            <artifactId>jsf-impl</artifactId>
            <version>2.1.3</version>
        </dependency>
    </dependencies>
    <build>
        <defaultGoal>clean jetty:run</defaultGoal>
        <plugins>
            <plugin>
                <groupId>org.mortbay.jetty</groupId>
                <artifactId>jetty-maven-plugin</artifactId>
                <version>8.1.3.v20120416</version>
                <configuration>
                    <webApp>
                        <overrideDescriptor>src/main/webapp/WEB-INF/web-add.xml</overrideDescriptor>
                    </webApp>
                    <contextXml>src/main/webapp/WEB-INF/jetty-context.xml</contextXml>
                </configuration>
            </plugin>
        </plugins>
    </build>
</profile>

Don’t forget the 3 files above jetty-env.xml to define JNDI, web-add.xml to override web.xml with CDI servlet bootstrapping and JNDI and jetty-context.xml to expose the internal servlet implementation for Weld decorator.
With this Maven profile, we only have to enter mvn -Prun to build our web application and have it launched in Jetty to test it. Hard to make it simpler.

Check our code

Feel free to look at Socializer code and play with our API. Contribution are always welcome.