Skip to main content

Java Portlet Specification


Introduction

The Java Portlet Specification provides a standard for developing portal components with the Java programming language. This specification, originally released in October 2003 called as JSR168, is gaining popularity as not only a standard for traditional portals, but also as a framework for deploying 'plug-ins' for standard Web applications.

Currently there are three Java Portlet Specifications as JSR168, JSR170 and JSR 286.

JSR 168

JSR168 is a standard relating to portlets within Java-based portals. JSR168 defines a standard set of behavior for portlets and a standard interface that governs how portlets interact with the portlet container (typically a portal package) in which they are hosted. In simple way it defines a portlet specification, including a contract between the portlet container and the portlet. JSR 168 is defined by the Java Community Process (JCP) in October 2003.

Goals of JSR168

• Define the runtime environment, or the portlet container for portlets.
• Define the API between portlet container and portlets.
• Provide mechanisms to store transient and persistent data portlets.
• Provide a mechanism that allows portlets to include servlets and JSP.
• Define a packaging of portlets to allow easy deployment.
• Allow binary portlet portability among JSR168 portals.
• Run JSR168 portlets as remote portlets using WSRP protocol.

JSR 168 offers numerous useful portal-specific capabilities as follows.

• Portlet modes – JSR 168 provides three modes for portlet interactions.
VIEW - This mode, a mandatory one that's defined by a portlet, renders markup fragments.
EDIT - This optional mode enables changes to per-user settings to customize rendering.
HELP – This optional mode displays help information.

The major changes and enhancements of JSR168

• Decoupling the portlet class from servlets.
• Ensuring that JSR168 aligns well with the emerging WSRP specification in areas such as URL rewriting, portlet modes, window states, multistep navigational state and portal container context.
• Offering general architectural cleanup to allow for flexibility and extensibility over time.
• This standard ensures that portlets were cross-vendor and -server compatible.

Issues in JSR 168

• Inter-portlet communication and event model. This is arguably the most important gap in the JSR168 specification
• Provision for client-side portals.
• Tight coupling with one or more user interface frameworks, such as Struts, Java Server Faces (JSF) and Barracuda.

JSR170

JSR-170 is a specification developed under the Java Community Process (JCP) program in April, 2005.
It promises the Java world, and possibly beyond, a unified API that allows accessing any compliant repository in a vendor- or implementation-neutral fashion, leading to the kind of clean separation of concerns that characterizes modern IT architectures.
The JSR-170 API defines how an application and a content repository interact with respect to a number of content services. For example the versioning facilities of a content repository are clearly defined, so an application knows how to browse the version history, check in and checkout content items, or update and merge content in a standard fashion.

JSR 286

While JSR-168 laid the foundation for the portal architecture, it lacked many features that applications and developers needed. This forced developers back into creating non-portable, vendor-specific solutions, which therefore defeated the very purpose of having a portal specification. Then The Java Portlet Specification V2.0 (JSR-286) was created to enhance JSR-168 and improve upon its shortcomings. On June 12th, 2008, JSR-286, went final and was publicly released.

Major enhancements of JSR 286
  • WSRP 2.0 alignment
  • Serving AJAX or JSON data directly through portlets
  • Serving dynamically generated resources directly through portlets
  • Inter-Portlet Communication through events
  • Setting Markup Head Elements
  • Caching Changes
  • Public Render Parameters
  • Window ID / Namespacing Consistency
  • Additional CSS classes
What was left out of the JSR286 Specification
  • Clear Read / Write AJAX support
Developers have no way to make sure other Portlets receive state change information, when updating state through a Resource URL.
  • Improved Groups and Permissions Support
  • More CSS Classes
Although some additional CSS classes have been defined by the JSR 286 specification, they are insufficient to meet the demands of good user interfaces.

Comments

Popular posts from this blog

Convert an InputStream to XML

For that we can use DocumentBuilder class in java. By using the method parse(InputStream) ; A new DOM Document object will return. InputStream input; DocumentBuilderFactory factory = DocumentBuilderFactory.newInstance(); DocumentBuilder parser = factory.newDocumentBuilder(); Document dc= parser.parse(input); In the above code segment,by using the created Document object,the corresponding XML file for the inputStream can be accessed. References: http://www.w3schools.com/dom/dom_intro.asp http:// download.oracle.com/javase/1.4.2/docs/api/javax/xml/parsers/DocumentBuilder.html

CORS support from WSO2 API Manager 2.0.0

Cross-origin resource sharing (CORS) is a mechanism that allows restricted resources  on a web page to be requested from another domain outside the domain from which the first restricted resource was served. For example, an HTML page of a web application served from http://domain-a.com makes an <img src >  request for a different domain as 'domain-b.com' to get an image via an API request.  For security reasons, browsers restrict cross-origin HTTP requests initiated from within scripts as in above example and only allows to make HTTP requests to its own domain. To avoid this limitation modern browsers have been used CORS standard to allow cross domain requests. Modern browsers use CORS in an API container - such as  XMLHttpRequest  or Fetch - to mitigate risks of cross-origin HTTP requests.Thing to  note is it's not only sufficient that the browsers handle client side of cross-origin sharing,but also the servers from which these resources getting need to handl

[WSO2 AM] APIStore User Signup as an approval process

In previous versions of WSO2 APIManager before 1.6.0, it was allowed any user who's accessible the running APIStore come and register to the app.But there will be requirement like,without allowing any user to signup by him/her self alone,first get an approve by a privileged user and then allow to complete app registration.Same requirement can be apply to application creation and subscription creation as well.To fulfill that,we have introduced workflow extension support for  WSO2 APIManager  and you can find the introductory post on this feature from my previous blog post on " workflow-extentions-with-wso2-am-160 " . From this blog-post,I'll explain how to achieve simple workflow integration with default shipped resources with  WSO2 APIManager 1.6.0 and WSO2 Business Process Server 3.1.0 with targeting "user-signup" process. Steps First download the WSO2 APIManager 1.6.0[AM] binary pack from product download page . Extract it and navigate to