PortalTeam portlets published.

By Alexander Oleynik, On 01/18/2010 6:30 PM

We are proud to announce the PortalTeam portlets pack available for download. This portlets pack is considered to be a bunch of portlets developed by PortalTeam.net for internal use. But we hope people will find them useful too.

Currently there is only Web Form portlet. More to come soon.

Web Form features:

JSR 286 : The Eventing feature

By Yuri Voloshenyuk, On 21/12/09 10:19 PM

In order to provide coordination between portlets the Java Portlet Specification, JSR 286 introduces the  following mechanisms

In this blog, i will explain the Eventing feature and in a later blog i will explain the Public Render Parameter feature.

Eventing can be described as a loosely coupled, brokered means of communication between portlets. It is intended to allow portlets to react on actions or state changes not directly related to an interaction of the user with the portlet.
Events are a lifecycle operation that occurs before the rendering phase.


Now let us get into the details of writing portlets that use this feature

The portlet can declare the events in its deployment descriptor using the event-definition element in the portlet application section. In the portlet section each portlet can specify the events it would like to publish via the supported-publishing-event element and the events it would like to process via the supported-processing-event element. The supported-publishing-event and supported-processing-event element must reference the event name defined in the portlet application section in a event-definition element.

The portlet issues events via the setEvent method during the action processing. This will be processed by the portlet container after the action processing has finished.

In order to receive events the portlet must implement the javax.portlet.EventPortlet interface. The portlet container will call the processEvent method for each event targeted to the portlet with an EventRequest and EventResponse object.
The portlet can access the event that triggered the current process event call by using the EventRequest.getEvent method. This method returns an object of type Event encapsulating the current event name and value.

Event names are represented as QNames in order to make them uniquely identifiable. The event name can be either retrieved with the getQName method that returns the complete QName of the event, or with the getName method that only returns the local part of the event name. The value of the event must be based on the type defined in the deployment descriptor.

Following are the steps to write portlets that make use of eventing feature

1.Declare the events in the portlet.xml
    1.1 Set the event definition at the portlet application level. This specifies the event name and the object type.
          Note: The object must be serializable.
    <portlet-app .....>
        <event-definition>
        <qname xmlns:x="http:sun.com/events">
            x:Address.Create
        </qname>
        <value-type>com.test.Address</value-type>
        </event-definition>

    1.2 In the portlet section, specify the event name defined above for those portlets that want to publish this event.
        <portlet>
            .................
            <supported-publishing-event xmlns:x="http:sun.com/events">
                    x:Address.Create
            </supported-publishing-event>

    1.3 In the portlet section, specify the event name defined above for those portlets that want to process this event.
        <portlet>
            .................
           <supported-processing-event xmlns:x="http:sun.com/events">
                  x:Address.Create
           </supported-processing-event>

    
2.Issue an event in the portlet that was specified as supported-publishing-event in the portlet
    @XmlRootElement
    public class Address implements Serializable
    {
        private String street;
        private String city;
        public void setStreet(String s) {street = s;}
        public String getStreet() { return street;}
        public void setCity(String c) { city = c;}
        public String getCity() { return city;}
    }

    void processAction(ActionRequest request, ActionResponse response)
    {
        String myStreet = request.getParameter("street");
        String myCity = request.getParameter("city");
        Address sampleAddress = new Address();
        sampleAddress.setStreet(myStreet);
        sampleAddress.setCity(myCity);
        QName name = new QName("http:sun.com/events", "Address.Create");
        response.setEvent(name, sampleAddress);
    }     

3.Process the event in the portlet that has specified as supported-processing-event in the portlet
    void processEvent(EventRequest request, EventResponse response)
    {
        Event event = request.getEvent();
        if ( event.getName().equals("Address.Create") )
        {
            Address payload = (Address) event.getValue();
            .......
        }
    }

Site moved to Vosao CMS.

By Alexander Oleynik, On 9/22/09 8:14 PM

We are moving again. After 1 month of development our new Google App Engine project Vosao CMS reached a status of working prototype. And we decided to give it a real life test. Vosao CMS was started as an attempt to acquaint ourself with Google App Engine. So the first acquaintance took place.

Running JSF 1.2 on Google App Engine

By Alexander Oleynik, On 7/10/09 12:19 PM

Finally after JSF 1.2 updated to version 1.2_13 it's now possible to use JSF 1.2 on GAE.

The requirements:

Lines of configuration in web.xml:

<context-param>
<param-name>com.sun.faces.enableMultiThreadedStartup</param-name>
<param-value>false</param-value>
</context-param>
<context-param>
<param-name>com.sun.faces.expressionFactory</param-name>
<param-value>com.sun.el.ExpressionFactoryImpl</param-value>
</context-param>
 

Project source code is available.

Using Facelets with SUN JSF portlet bridge

By Alexander Oleynik, On 6/10/09 8:46 AM

Problem description

To have multiple instances of the same portlet reside on the same portal page, you need to embed the portlet's JSF tags within a portletPage tag. Unfortunately jsf-portlet.jar contains JSP tag description only. And when using facelets portletPage tag just being rendered to result html page us regular html tag.

Solution

Add facelets taglib file jsf-portlet.taglib.xml to jsf-portlet.jar/META-INF directory

<?xml version="1.0"?>
<!DOCTYPE facelet-taglib PUBLIC
"-//Sun Microsystems, Inc.//DTD Facelet Taglib 1.0//EN"
"facelet-taglib_1_0.dtd">

<facelet-taglib>
<namespace>http://java.sun.com/jsf/portlet/components</namespace>
<tag>
<tag-name>portletPage</tag-name>
<component>
<component-type>PortletComponent</component-type>
</component>
</tag>
</facelet-taglib>

Here you can dowload fixed jsf-portlet.jar

Using file upload in Liferay JSF portlet.

By Alexander Oleynik, On 6/9/09 2:41 PM

Problem description

It is not possible to use upload file control when using JSF 1.2 RI + Sun JSF portlet (Liferay Portal 5.1.2)

When I changed form enctype to "multipart/form-data" my jsf action stopped to run. The reason is in the fact that when form enctype is "multipart/form-data" bridge doesn't parse request and not filling parameters map.

Solution

Create custom JSF portlet and wrap "multipart/form-data" ActionRequest into such with parsed parameters with added upload file controls as a request attributes.

So having JSF:

<h:form enctype="multipart/form-data">
<input type="file" name="resumeFile" />
<h:commandbutton value="Apply" action="#{newJobsView.submitApply}">
</h:commandbutton>
</h:form>

In JSF action you can get attached file as:

public void submitApply() {
FacesContext facesContext = FacesContext.getCurrentInstance();

// JSFPortletUtil - Liferay provided class from util-bridges.jar
ActionRequest request = JSFPortletUtil.getPortletRequest(facesContext);

// FileItem is from commons-fileupload.jar
FileItem item = (FileItem)request.getAttribute("resumeFile");
...

}

First my File upload util class:

package com.oleynik.util;

import java.util.HashMap;
import java.util.List;
import java.util.Map;

import javax.portlet.ActionRequest;

import org.apache.commons.fileupload.FileItem;
import org.apache.commons.fileupload.FileItemFactory;
import org.apache.commons.fileupload.FileUploadException;
import org.apache.commons.fileupload.disk.DiskFileItemFactory;
import org.apache.commons.fileupload.portlet.PortletFileUpload;

public class FileUploadUtil {

public static boolean isMultipart(final ActionRequest request) {
return PortletFileUpload.isMultipartContent(request);
}

public static List<FileItem> parseRequest(final ActionRequest request)
throws FileUploadException {
FileItemFactory factory = new DiskFileItemFactory();
PortletFileUpload upload = new PortletFileUpload(factory);
return upload.parseRequest(request);
}

public static Map<String, String> getParameters(final List<FileItem> items) {
Map<String, String> result = new HashMap<String, String>();
for (FileItem item : items) {
if (item.isFormField()) {
result.put(item.getFieldName(), item.getString());
}
}
return result;
}

public static Map<String, FileItem> getFiles(final List<FileItem> items) {
Map<String, FileItem> result = new HashMap<String, FileItem>();
for (FileItem item : items) {
if (!item.isFormField()) {
result.put(item.getName(), item);
}
}
return result;
}
}

Second is Wrapper ActionRequest class:

package com.oleynik.faces;

import java.util.Collections;
import java.util.Enumeration;
import java.util.HashMap;
import java.util.List;
import java.util.Map;

import javax.portlet.ActionRequest;
import javax.portlet.filter.ActionRequestWrapper;

import org.apache.commons.fileupload.FileItem;
import org.apache.commons.fileupload.FileUploadException;

import com.oleynik.util.FileUploadUtil;
import com.liferay.portal.kernel.log.Log;
import com.liferay.portal.kernel.log.LogFactoryUtil;

public class FileUploadActionRequestWrapper extends ActionRequestWrapper {

private static final Log logger = LogFactoryUtil.getLog(
FileUploadActionRequestWrapper.class);

private Map<String, String[]> parameters;

public FileUploadActionRequestWrapper(final ActionRequest request)
throws FileUploadException {
super(request);
parameters = new HashMap<String, String[]>();
if (FileUploadUtil.isMultipart(request)) {
//logger.info("multipart");
List<FileItem> items = FileUploadUtil.parseRequest(request);
Map<String, FileItem> files = FileUploadUtil.getFiles(items);
for (String name : files.keySet()) {
setAttribute(files.get(name).getFieldName(), files.get(name));
//logger.info("file " + files.get(name).getFieldName());
}
Map<String, String> pars = FileUploadUtil.getParameters(items);
for (String name : pars.keySet()) {
String[] values = new String[1];
values[0] = pars.get(name);
parameters.put(name, values);
}
}
}

@Override
public Map<String, String[]> getParameterMap() {
return parameters;
}

@Override
public String getParameter(final String name) {
if (parameters.get(name) != null) {
return parameters.get(name)[0];
}
return null;
}

@Override
public String[] getParameterValues(final String name) {
return parameters.get(name);
}

@Override
public Enumeration<String> getParameterNames() {
return Collections.enumeration(parameters.keySet());
}
}

And finally custom JSF portlet class:

package com.oleynik.faces;

import java.io.IOException;

import javax.portlet.ActionRequest;
import javax.portlet.ActionResponse;
import javax.portlet.PortletException;

import org.apache.commons.fileupload.FileUploadException;

import com.oleynik.util.FileUploadUtil;
import com.liferay.portal.kernel.log.Log;
import com.liferay.portal.kernel.log.LogFactoryUtil;

public class FacesPortlet extends com.sun.faces.portlet.FacesPortlet {

private static final Log logger = LogFactoryUtil.getLog(FacesPortlet.class);

public FacesPortlet() {
super();
//logger.info("init");
}

@Override
public void processAction(ActionRequest request, ActionResponse response)
throws IOException, PortletException {

ActionRequest myRequest = request;

if (FileUploadUtil.isMultipart(request)) {
//logger.info("multipart!");
try {
myRequest = new FileUploadActionRequestWrapper(request);
} catch (FileUploadException e) {
logger.error(e.getMessage());
}
}
super.processAction(myRequest, response);
}
}

Set custom JSF portlet in your portlet.xml file

<?xml version="1.0"?>
<portlet-app
xmlns="http://java.sun.com/xml/ns/portlet/portlet-app_2_0.xsd"
version="2.0"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://java.sun.com/xml/ns/portlet/portlet-app_2_0.xsd
http://java.sun.com/xml/ns/portlet/portlet-app_2_0.xsd">

<portlet>
<portlet-name>1</portlet-name>
<display-name>JSF upload example</display-name>
<portlet-class>com.oleynik.faces.FacesPortlet</portlet-class>
<init-param>
<name>com.sun.faces.portlet.INIT_VIEW</name>
<value>/view.xhtml</value>
</init-param>
<supports>
<mime-type>text/html</mime-type>
<portlet-mode>view</portlet-mode>
</supports>
<portlet-info>
<title>JSF upload example</title>
<short-title>JSF upload example</short-title>
<keywords>JSF upload example</keywords>
</portlet-info>
<security-role-ref>
<role-name>administrator</role-name>
</security-role-ref>
<security-role-ref>
<role-name>guest</role-name>
</security-role-ref>
<security-role-ref>
<role-name>power-user</role-name>
</security-role-ref>
<security-role-ref>
<role-name>user</role-name>
</security-role-ref>
</portlet>
</portlet-app>

Note: this implementation uses commons-fileupload.jar and commons-io.jar. Created example portlet with sources is available for download.

LifeRay - Social Networking & CMS Web Publishing

By Alexander Oleynik, On 4/20/09 7:30 PM

LifeRay is one of the leading open source CMS software platforms available for social networking, portal development, business intranets, corporate extranets, forums, archives, and general web publishing. LifeRay has already been downloaded over 1 million times, with an average of over 60,000 downloads per month. The software comes with numerous bundled versions and has already won accolades such as the InfoWorld 2007 Technology of the Year Award for Best Open Source Portal.

The LifeRay Portal is composed of two main sections: the LifeRay Journal and the LifeRay Collaboration Suite. The LifeRay Journal is the content management system of the portal, allowing web publishers to easily post content, manage pages, create hierarchical menus, and site structure. The LifeRay Collaboration Suite is the social networking aspect of the portal, which includes forums, wiki collaboration, blogs, email, calendars, and tagging. Both of these can be extended by open source “portlets” that add increased functionality to the system.

The LifeRay Journal:

LifeRay Journal is LifeRay Portal’s built-in content management system (CMS) ready to deliver portal-based web publishing and document management.

The LifeRay Collaboration Suite:

Forums:

Blogs:

Wikis:

Other Features:

Portlets:

There are many benefits to the LifeRay Portal software, first and foremost of which are its open source code base and large community of international users. LifeRay provides an intuitive and collaborative user experience and allows publishers to consolidate, organize and access all their data and applications via a single point of access. It is also a cost effective way to optimize your development costs and adapt to the demands of a changing market.

The LifeRay CMS has one of the most impressive client lists of any open source portal software. From IT, Financial Services, and Retail Companies, to Non-Profits, Educational Groups, and Governmental Agencies, LifeRay CMS has hundreds of thousands of web sites deployed with its architecture. The professionalism, scalability, and affordability of LifeRay make it a wise choice for any web development department.

Sun GlassFish Web Space Server 10

By Alexander Oleynik, On 4/10/09 10:58 AM

Sun GlassFish Web Space Server 10

Sun's Next-generation Portal Server Platform

Sun's next-generation portal server platform, Sun GlassFish Web Space Server enables organizations to pull together applications and content from a variety of Web-based and internal sources and present them as a unified, customizable portal on Web browsers, kiosks, and mobile devices. GlassFish Web Space Server offers features for general users, system administrators, and application and portal developers.

FEATURES

The Sun GlassFish Web Space Server 10.0 release is based on the Liferay portal server community edition 5.2. Key features include:

Some of the specific and latest features in release 10.0 of this Web Space Server:

Web Services for Remote Portlets (WSRP) 2.0

OASIS recently approved this latest version of the WSRP specification and it is available in the Sun GlassFish Web Space Server from the Control Panel in the Welcome menu. This specification defines the following additional functionalities over the previous version 1.0:

The Sun GlassFish Web Space Server implements all the mandatory features and some of the major optional features that are defined in the WSRP version 2.0 specification. For more information, visit the WSRP project Web site.

Simple API for Workflow

For more information, visit the SAW project Web site.

Presence

The Presence infrastructure in Sun GlassFish Web Space Server provides communication mechanisms for a user who logs in to Sun GlassFish Web Space Server. The Presence infrastructure displays the online or offline status of a user and the chat communication mechanism, next to wherever the user profile is displayed on Sun GlassFish Web Space Server. Using the Presence infrastructure, developers can enable their widgets on Sun GlassFish Web Space Server with the availability information for a user. See the Presence project Web site.

Content Management System

Now use the Web Content tag library to access the content of an article from any portlet in Sun GlassFish Web Space Server. Learn more at the Content Management System/Mirage project Web site.

Control Panel for Sun GlassFish Web Space Server Administration

In the Sun GlassFish Web Space Server 10.0 release, all the administrator portlets can be accessed by clicking Control Panel in the Welcome menu. In the previous releases, you were able to access these portlets by clicking Add Application.

Sun GlassFish Web Space Server Samples

Default samples are available in Sun GlassFish Web Space Server 10.0. A number of users and a community are created and provided basic layouts with default public and private pages to demonstrate Sun GlassFish Web Space Server functions. The default samples that are available include Social Space, CMS, and Enterprise Space. All the samples and a "Sample Users" portlet, which can be used to express login different users of different samples, are a part of an evaluation bundle of the Sun GlassFish Web Space Server.

Portal Coordination Service

This feature bridges portlet events to portal services, allowing portlets to publish standard JSR 286 portlet events to interact with Sun GlassFish Web Space Server services. The Portal Coordination Service available in the release bridges to the Sun GlassFish Web Space Server social activity service.

The Roller Weblogger portlet makes use of the Portal Coordination Service to add Roller Weblog posts and edits to the set of social activities. These are summarized in the activities portlet.

Developer Tools

Visit the portal pack project Web site for more details.

Eclipse Portal Pack

This software provides a set of plugins to help develop JSR 168/286 portlets and deploy them on supported portlet containers. For more information, visit the Eclipse Portal Pack project Web site.

ViewDesigner Plugin

This plugin enables a Web designer to design and customize the theme of a portal page. You can download the plugin from the ViewDesigner project Web site. Learn more about designing and customizing a theme by visiting the Sun GlassFish Web Space Server 10.0 Developer’s Guide.

SYSTEM INFORMATION

Product System Requirements

Supported Platforms

GlassFish Enterprise Server V2 update 2 or later

Supported Operating Systems

Upgrade Plan

GlassFish Web Space Server is the follow-on product to Sun Java System Portal Server, so existing 6.x and 7.x customers can upgrade their existing entitlements to Web Space Server for no additional license fee.

Google App Engine now supports Java

By Alexander Oleynik, On 4/9/09 12:05 PM

Google on Tuesday evening announced a new version of its Google App Engine application-hosting service that adds multiple capabilities, including new support for the Java programming language.

 Improvements are intended to make the Google App Engine infrastructure available to all developers, ranging from those at startups to IT administrators inside the enterprise, Google said. In addition to Java support, other features in the updated version of Google App Engine include database import and export, access to firewalled data, and cron support, which enables configuration of regularly scheduled tasks to operate at defined times.

Google has been running internal and external applications on its Google App Engine and it has not been without difficulty, said Kevin Gibbs, tech lead for Google App Engine, in a blog post on Tuesday evening.

"Tonight at Campfire One, we released a new set of features -- based on community and internal feedback -- that helps App Engine interface more easily with businesses' existing technologies,"Gibbs wrote. Campfire One features a gathering of developers at company facilities.

Early support for Java includes a Java runtime, integration with the Google Web Toolkit 1.6, and a Google Plugin for Eclipse. Developers can program against Java Data Objects or Java Persistence API. Until now, Google App Engine has only leveraged Python.

Also highlighted in the Google App Engine upgrade were Google Secure Data Connector, for centrally managed access to on-premise data, and a data import tool to move gigabytes of data into App Engine. Cron support, according to a link to the blog, is geared to the Python language.

"By reducing the administrative headaches that come with scaling and distributing an application, we hope that App Engine will continue to let developers do what they do best: launch services that delight users," Gibbs said.

In the past six months, Google has launched nearly 50 projects and small products on Google App Engine, including Google Moderator, for distributed communities to vote on subjects, Gibbs said.

"In all cases we found it quicker, easier, and more cost-effective to leave the infrastructure to App Engine and the actual product-building to our engineering teams," said Gibbs.

Site moved to Liferay portal.

By Alexander Oleynik, On 4/8/09 4:14 PM

Today site was moved to Liferay portal. Also we added blog page where will be PortalTeam.net news and Java portals news.