Hi All, best wishes to all of you, a happy new year! Sorry for not participating for such a long time - I simply didn't find enough time to contribute to the jetspeed development in a sensible way. Hope this gets better this year... :-\
I think the JSR question is an important decision and as an "IBMer", I'll obviousely support the proposal... ;-) At 06:43 12/29/01, David Sean Taylor wrote: >Hi All, > >With the coming of the new year, I am looking forward to moving on to >Jetspeed-2. > >The first subject to discuss is whether the Jetspeed developers would like >to support the Portlet API standards effort, and participate in the JCP >expert group. > >I'd like to then call for a vote on: > >(1) Does the Jetspeed Community support the Portlet API Standard being >defined in the Java Community Process (so that it will be standardized in >the context of J2EE) This implies that we will base Jetspeed-2 on the new >proposed standard. +1 >(2) If yes, does the Jetspeed Community want to participate by sending >Jetspeed Developer(s) to the Portlet API JSR Expert Group ? +1 I like Davids idea of having a representative who votes according to the outcome of our voting process! > The committer(s) who are expert members of the group will vote. > However, we could vote in the usual apache way (+1 -1) on the list, and > then have our representatives make the final vote in the JCP group. +1 ingo. >The JSR is yet to appear at jcp.org. >I've included below Thomas's description (again) of the Portlet API >specification, which contains much of the same text as sent to the JCP. > >David > >---------------------------------------------------------------------------- >The Portlet API specification defines an API for web application components >that interact with and can be aggregated in web applications like portals. >We refer to these components as portlets in the remainder of this text. > > >Portlets are web components like servlets, but have additional, special >properties that allow them to easily plug into and run in enclosing web >applications like portals. Portlets are designed to be aggregatable in the >larger context of composite pages, e.g. multiple instances of the same >portlet parameterized with different per-user, per-instance portlet data >can coexist on the same portal page. Usually, many portlets are invoked in >the course of handling a single request to aggregate their respective >produced markup fragments in a page of markup. The markup fragments >generated by portlets often need to contain links to trigger actions in the >portlet, therefore URL-rewriting methods are required that allow portlets >to transparently create links within the markup fragments they output, >without needing to know how URLs are structured in the particular web >application. > > >Portlets rely on the portlet container infrastructure accessible via the >Portlet API for functions like access to user profile information for the >current user, access to the window object that represents the window in >which the portlet is displayed, participation in the portal window and >action event model, access to web client information, inter-portlet >messaging and a standard way of storing and retrieving >per-user/per-instance data persistently. > > >The Portlet API provides standard interfaces for the functions mentioned >above. The Portlet API extends the servlet programming model and defines a >common base class and interfaces for portlets and tags for JSPs called by >portlets, cleanly separating portlets from the surrounding infrastructure >so that portlets can run on different portal servers like servlets can run >on different application servers. > > >The Portlet API specification shall evolve from the portlet concept as >developed in the Apache JetSpeed Open Source project. In many aspects, the >Portlet API is an extension of the Servlet API, defining additional >interfaces for portlet-specific functionality. In some other aspects, it >restricts use of functions provided by the Servlet API to the subset that >makes sense for portlets just producing aggregatable markup fragments and >not having ownership of the entire page that displays them. For example, >unlike servlets, portlets may not send errors or redirects as a response, >this may only be done by the application that invokes and aggregates the >portlets into a larger page. > > >Portlets can be grouped in Portlet Applications. Portlets in one portlet >application can exchange messages via the Portlet API. Portlet Applications >are packaged, distributed and deployed using WAR files that include >portlet-related meta-information, utilizing existing Servlet >infrastructure. > > >The Portlet API shall be compatible with the Remote Portlet Web Services >concept in the sense that portlets written to the Portlet API can act as >local proxies in a portal server for remote portlet web services located on >other servers and portlets written to the Portlet API can be wrapped into >remote portlet web services. > > > >-- >To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> >For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
