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

Post a Comment

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
2 comments
Read more

Concat two xml values with XSLT

The use-case described in this blog-post,is there's an WSO2 ESB node setup to proxy an incoming message to a particular back-end endpoint.  Before delivering the message to the back-end endpoint,from the ESB node itself,this incoming message need to processed and change its inside xml payload format. For eg: Below is the incoming message <?xml version="1.0" encoding="UTF-8"?> <CinemaHall name="liberty"> <OwnerData> <Name>John Smith</Name> <openedDate>12/12/80</openedDate> <quality>good</quality> </OwnerData> <CinemaHallData> <rows>100</rows> <seats> <seat>50</seat> <seat>60</seat> </seats> </CinemaHallData> </CinemaHall> This message need to be changed as  below; <?xml version="1.0" encoding="UTF-8"?> <CinemaHall name="liberty"...
3 comments
Read more

Passing end-user details from client to real backend endpoint via JWT token

In real-world business system,WSO2 API Manager useful on exposing company APIs, in a secured and controlled manner with the features provided by APIManager as; OAuth support [To secure API invocations] Throttling support [To control API invocations] Monitoring support [To track API usage] More technically what happening is when a user sends a particular API request,it will goes to WSO2 APIManager node and from there,the request will route to the real implemented back-end endpoint of the particular API and get back the response and returned it to the API invoked user. There can be a use-case,that this back-end endpoint may expect the details of API invoked user as to pass those details to some internal company usage  as; Additional authentication/authorization Track usage data from an internal system. So how to support above requirement from WSO2 AM. There comes the use of JSON Web Token[JWT] implementation done inside WSO2 AM. JWT is a means of representing claims to...
7 comments
Read more