Customers can begin prototyping modern Java applications for the forthcoming eXo Platform 3.0 through new program
SAN FRANCISCO, CA (July 21, 2010) – eXo today announced the eXo Early Adopter Program designed to give Java enterprises access to the training and technical resources they need to begin rolling out cutting-edge, rich Java applications built on eXo Platform 3.0. The company’s much-anticipated flagship offer, planned for general availability by the end of the year, has been re-architected with the fast, modern portal framework co-developed by eXo and Red Hat, GateIn.
In recent months, eXo has delivered new and updated community versions of all the key components in eXo Platform 3.0 to run on GateIn 3.0: eXo Social, eXo Content, eXo Collaboration and eXo Knowledge. The Early Adopter Program goes beyond a beta program, and instead offers eXo’s most innovative customers and other Java enterprises a realistic path to modernizing their legacy Java applications.
The training and developer support offered through the Early Adopter Program is designed to help developers begin prototyping a new breed of rich, interactive, social Java applications that can run popular Java environments such as JBoss, Spring, Tomcat or IBM WebSphere. Applications developed today will be compatible with the GA release. These services will be delivered by eXo’s technical product leaders.
Program Details
Early access to all updates between now and final GA.
Three-hour web-based trainings on all eXo components comprising eXo Platform 3.0.
One-year Developer Subscriptions, giving users support on community and beta releases.
Discounts on eXo Platform 3.0 Production Subscriptions down the road.
Participation in the Early Adopter Program is a one-time $5,000 fee, which can be applied to the future purchase of a Production Subscription.
Supporting Quotes
Benjamin Mestrallet, founder and CEO of eXo: “The enthusiasm we’re seeing for eXo Platform 3.0, even in this early stage, validates the heavy investment we’ve made to deliver the best user experience platform on the market for Java enterprises. The Early Adopter Program, which we initially opened to select customers, has been so well received that we’re opening it up to more enterprises looking for a ‘SharePoint’ of their own that would work with their existing Java systems and make the most of their Java talent. This program puts the power of the eXo Platform in developers’ hands, with a practical roadmap to get them from design and development to production.”
eXo Web Content Management 2.0 now available as open source download
San Francisco, Calif. (June 15, 2010) – eXo (http://exoplatform.com) today released eXo Web Content Management (WCM) 2.0. Bundled with GateIn 3.0 and Tomcat 6.0 to run out of the box, eXo WCM is now available as a free download under the open source Affero Gnu Public License (AGPL). Commercial support for eXo WCM will be available as part of eXo Platform 3.0, expected later this year.
Why Use eXo WCM
Like all eXo services, such as eXo Social (announced just last month), eXo WCM is designed for IT organizations that want to be able to integrate web content with their existing enterprise Java systems. eXo WCM comes with tools and extensions already familiar to Java programmers, so they can starting developing from day one.
On its own, eXo WCM provides all the modern Web 2.0 capabilities needed to create, publish and manage web content. It runs with GateIn, the advanced new portal framework created by eXo and Red Hat, so users now have content management inside a portal. Users can integrate applications in the portal and manage all the content from the same user interface.
With eXo WCM as a core piece of the eXo Platform, Java enterprises have a comprehensive user experience platform for integrating intranet, Web and transactional applications – similar to what SharePoint provides for .NET.
Highlights of eXo WCM
Visit the eXo site for a full list of eXo WCM features. Highlights include:
Scalable Content: eXo WCM is based on eXo JCR, an open source implementation of the Java Content Repository specification. This implementation has been in production for several years within large productions environments with tens of thousands of users and millions of documents.
Ease of Use: eXo WCM makes it easy to create, approve and deploy content as part of an overall Java web application. Search, Favorites, Tagging, Voting, Cover Flows, Timelines, Versioning and Locking are all easily enabled for content users.
Customizability: eXo WCM can be customized to suit project needs. Users can change the content repository structure and use their own metadata, for example; choose from different content templates, or create new ones; and create specific views based on roles.
Extensibility: eXo WCM comes with ready extensions for adding document management and workflow. This package also includes a preview of a new authoring publication extension for more contextual and dynamic content life cycles. Users can create their own plugins and extensions to make eXo WCM work for them.
Flexibility: With eXo WCM, users can slice and dice their content in several ways and publish in multiple places with different workflows. Even if stored in just one repository, content can be classified in different hierarchies, tagged for public or private view and “favorited” so it can be quickly accessed from an individual’s private drive.
Supporting Quotes
Benjamin Mestrallet, founder and CEO of eXo: “With eXo WCM, Java enterprises have a complete portal and content management system in a single software package — eliminating the need to cobble together solutions from different vendors. Anyone can start using eXo WCM on its own today. But for those enterprises looking for an elegant, integrated way to modernize their Java applications, eXo WCM is a hint of what’s to come with the eXo Platform.”
eXo will attend the “Solutions Intranet et Travail Collaboratif” event on May 5th and 6th in Paris. Come to meet us to talk about Intranets and Collaborative Solutions eXo is offering. It also will be a nice opportunity to share about industry trends and new eXo developments.
Content Management Interoperability Services (CMIS) is a standard for improving interoperability between Enterprise Content Management systems. It’s a new standard to make Document Management more interoperable.
A year and half ago, I already wrote a web service in java to edit documents, stored in the JCR, with Zoho. As CMIS arrive, it seems a good idea to rewrite this one with this standard and using groovy. Last time, I used a greasemonkey script to integrate it in eXo ECM, but this time, I’m going to create a gadget for that. Thanks to GateIn Gadget Dashboard, I’ll be able to follow multiple repository in one page and edit their files.
Requirements for this project
Browse the CMIS repository
If file can be edited with Zoho, offer this possibility
Work in the main browsers
Work with all the public CMIS demo servers available
What you need to know before starting
Basic knowledge of the gadget API. If you don’t have a look at the Gadget Developer Guide
CMIS servers make available 2 types of API: SOAP and Atom. From javascript, it’s easier to use the Atom API. But all the browsers don’t handle namespaces the same way, so it makes it harder to parse response. We are going to use JQuery because it makes things easier than using the native javascript functions, but I guess it’s possible to do the same with YUI, Dojo or other…
Parsing Atom in Javascript
To get a namespaced node with jQuery, you can do:
//this doesn't work because the : is used by the selector syntax of JQuery
var vendor = $(xmlNode).find("cmis:vendorName").text();
//this work in IE and Firefox but not in Webkit (Chrome and safari)
var vendor = $(xmlNode).find("cmis\\:vendorName").text();
//This is going to work on IE, Webkit (Chrome and safari) and Firefox.
var vendor = $(xmlNode).find("[nodeName=cmis:vendorName]").text();
So with this, I created a simple CMIS response parser in javascript: jquery.cmis.js (jsDoc). It can parse a Service, a Feed or an Entry.
To get the workspaces from a service:
//We parse the response sent by the CMIS service
var workspaces = CMIS.parse(XMLDocument);
//We take the first workspace
var current_workspace = workspaces[0];
// show the vendor of the first workspace
alert(current_workspace.getVendorName());
// Get the url pointing to the root directory listing
var root_feed = current_workspace.collections["root"];
To list a feed’s entries:
//We parse the response sent by the CMIS service
var feed = CMIS.parse(XMLDocument);
feed.getEntries().each(function(i, entry) {
// return if the entry is a folder
if (entry.isFolder()) {
// title of the folder
entry.title;
// get the link to browse the directory
entry.getLinks("down");
} else {
// title of the document
entry.title;
//URL of to get the content of the document
entry.getContentUrl();
}
}
Loading the feed from the gadget
So now that we know how to parse the response of a CMIS server. We can start building our gadget. Most (all?) the CMIS repository are using BasicAuth as authentication/authorization mechanism, so if our CMIS server is on the same domain name we could directly send a request to it. But as we want to be able to integrate CMIS server from all over the internet, we need to use a proxy (remember the same origin policy of our browsers).I’d love to see CMIS repositories to use oAuth authorization mechanism, but as it’s not the case for now, we need to write a simple proxy in Groovy and JAX-RS to do the authentication for us:
import javax.ws.rs.FormParam
import javax.ws.rs.Path
import javax.ws.rs.POST
@Path("proxy")
public class Proxy {
@POST
@Path("basic_auth")
public String basic_auth(@FormParam("url") String url, @FormParam("login") String login,
@FormParam("password") String password) {
return get(url, login, password);
}
public static String get(String url, String login, String password) {
// Basic Auth send login and password encoded in Base 64 in the header
def encoded = "$login:$password".getBytes().encodeBase64().toString()
def c = new URL(url).openConnection()
c.setRequestProperty("Authorization", "Basic $encoded")
return c.content.text
}
}
So to get a URL authenticated you can just call a url like this:
From our gadget, to get the response of the CMIS server using our proxy, we are going to do:
var params = {},
prefs = new gadgets.Prefs();
postdata = {
url: "http://cmis.exoplatform.org/rest/cmisatom",
login: prefs.getString("login"),
password: prefs.getString("password")
};
// our proxy need a POST
params[gadgets.io.RequestParameters.METHOD] = gadgets.io.MethodType.POST;
// We want the response as a DOM Document
params[gadgets.io.RequestParameters.CONTENT_TYPE] = gadgets.io.ContentType.DOM;
// We encode our parameters
params[gadgets.io.RequestParameters.POST_DATA] = gadgets.io.encodeValues(postdata);
// And finally we send our request
gadgets.io.makeRequest('http://cmis.exoplatform.org/rest/proxy/basic_auth', function(res) {
if (res.rc == 200) {
var response = CMIS.parse(res.data);
// We can do now what we want with the response...
} else {
alert("Error: " + res.data);
}
}, params);
We can now just use our response object to list the files on our repository.
3. Editing the files with Zoho
Now that we have successfully accessed to our files, we would like to edit them with Zoho editor (API documentation). We have to POST the file to their server, and they return the URL to edit it. When the user will save the document, the zoho server will do a POST on a callback URL (defined on our first POST) containing the document.
The service will download the file from the CMIS server
The service will generate an ID for the document. We are going to use the URL on the CMIS server and the login/password to access it. To avoid sending the login and password to zoho, we could have store it in the JCR but it add an extra step that we are not going to show on this tutorial.
The service will POST everything to the Zoho API corresponding to the right editor (Doc, spredsheet, presentation)
The service will parse the response and return the url of the editor
The gadget will redirect the user to the editor
When the user save the document, Zoho will do a POST on our service to save it
The service is going to push the document back on the CMIS server
It looks like a lot of things to do, but with groovy and JAX-RS it’s quite simple.
The gadget is going to call our edit service with the URL of the file and the credential needed in parameter:
@POST
@Path("edit")
public String edit(@FormParam("url") String url,
@FormParam("filename") String filename,
@FormParam("login") String login,
@FormParam("password") String password) {
//We prepare the request
def client = new HttpClient()
def ext = getExtension(filename)
def postMethod = new PostMethod(getZohoURL(ext))
//Get the content of the file we want to edit and continue to construct the request for the Zoho server
def src = new ByteArrayPartSource(filename, get(url, login, password))
Part[] parts = [
new FilePart("content", src), //content of the file we want to open
new StringPart("filename", filename), // filename of the document with extension
new StringPart("saveurl", callbackURL), //The Web URL should be a service that fetches the content of the updated document and saves it to the user specified location.
new StringPart("id", getId(url, login, password)), //unique id that will be submitted while saving the document (for reference)
new StringPart("format", ext) // the format in which document should be saved on remote server
];
postMethod.setRequestEntity(new MultipartRequestEntity(parts, postMethod.getParams()))
try {
// We send the request
def statusCode = client.executeMethod(postMethod)
// We transform the response into a hashmap
def resp = parseResponse(postMethod.getResponseBodyAsString())
//if the status is not 200 (OK) or there was a problem in the opening of the file we throw an exception
if (statusCode != 200 || resp["RESULT"] == "FALSE") {
throw new WebApplicationException(Response.status(Response.Status.INTERNAL_SERVER_ERROR).entity(resp["WARNING"]).type("text/plain").build())
}
//Everything went fine, so we return the URL to edit the file
return resp["URL"]
} finally {
postMethod.releaseConnection()
}
}
/**
* from the extension of the file, find which endpoint calling
*/
private String getZohoURL(String extension) throws IOException {
def url;
if (extension == null) {
throw new WebApplicationException(Response.Status.UNSUPPORTED_MEDIA_TYPE)
}
if (extension in ["doc", "rtf", "odt", "sxw", "html", "txt"])
url = "http://export.writer.zoho.com/remotedoc.im"
else if (extension in ["xls", "sxc", "csv"])
url = "http://sheet.zoho.com/remotedoc.im"
else if (extension in ["ppt", "pps"])
url = "http://show.zoho.com/remotedoc.im"
else
throw new WebApplicationException(Response.Status.UNSUPPORTED_MEDIA_TYPE)
url = url + "?apikey=" + apiKey + "&output=url"
return url;
}
Now that we have sent the file to zoho, we need to save it back on the CMIS server. Zoho will call the following method:
@POST
@Path("save")
@Consumes(["multipart/*"])
public String save(Iterator items) {
def stream
def id
// We loop over all the POST parameters to find the one that are interesting for us.
while (items.hasNext()) {
FileItem item = items.next();
if (item.getFieldName().equalsIgnoreCase("content")) {
stream = item.getInputStream()
}
if (item.getFieldName().equalsIgnoreCase("id")) {
id = new String(item.get());
}
}
// We are preparing the request to send to the CMIS server
// This time, we are going to send a PUT to update the content stream
def client = new HttpClient()
def putMethod = new PutMethod(getUrl(id))
try {
putMethod.setRequestBody(stream)
putMethod.setRequestHeader("Authorization", "Basic " + getCredential(id))
putMethod.setRequestHeader("Content-Type", "application/octet-stream")
def statusCode = client.executeMethod(putMethod)
// if everything went fine, we return a message that will be shown to the user
if (statusCode >= 200 && statusCode < 300)
return "Saved"
// If it did not go well, we send an error, and the user will be notified that something went wrong while trying
// to save his document
throw new WebApplicationException(statusCode)
} finally {
putMethod.releaseConnection()
}
}
The inherent challenge to developing software is maintaining and improving the quality of the code as you add features and expand the codebase over time.
To manage our code quality, we rely on Sonar. Sonar provides us views ranging from a high level global dashboard down to the most granular detail about individual lines of code – from these we can extract quality indicators from our code development.
GateIn, the new portal that eXo is co-developing with JBoss, provides a dashboard where you can install gadget and customize them. So we wrote gadgets that you can add to your dashboard and customize to your needs. As Gadget is a standard, it’s also working in Jira. Arnaud explain more about this:
Managing a product isn’t only about focusing on quality. We also have to deliver on time, meet our subscription customers’ requirements, and incorporate as many community feature requests as possible. To keep an eye on everything, we wanted to leverage the flexible interface of the GateIn portal framework. By integrating Sonar’s gadgets, we’ll be able to quickly create our own set of customized dashboards to track all the metrics we need, like the activity of our teams, development roadblocks, tasks and issues on products, and a lot more. We’re even able to reuse Jira Gadgets in GateIn – it saves us a lot of time and is definitely more effective.
Sonar Gadget in GateIn Dashboard:
Sonar Gadget in Jira4:
If you want to try these gadgets in your own development environment, you can grab them from Google App Gallery. They can work in any standard OpenSocial/gadget container, and they’ve been tested with GateIn and Jira.
If you want to look under the hood, go to the Sonar gadget repository on github or download them. You can also easily add your own metrics to the gadgets.