Return-Path: Delivered-To: apmail-jakarta-jetspeed-dev-archive@apache.org Received: (qmail 11851 invoked from network); 1 Nov 2002 04:41:37 -0000 Received: from unknown (HELO nagoya.betaversion.org) (192.18.49.131) by daedalus.apache.org with SMTP; 1 Nov 2002 04:41:37 -0000 Received: (qmail 13632 invoked by uid 97); 1 Nov 2002 04:42:37 -0000 Delivered-To: qmlist-jakarta-archive-jetspeed-dev@jakarta.apache.org Received: (qmail 13587 invoked by uid 97); 1 Nov 2002 04:42:37 -0000 Mailing-List: contact jetspeed-dev-help@jakarta.apache.org; run by ezmlm Precedence: bulk List-Unsubscribe: List-Subscribe: List-Help: List-Post: List-Id: "Jetspeed Developers List" Reply-To: "Jetspeed Developers List" Delivered-To: mailing list jetspeed-dev@jakarta.apache.org Received: (qmail 13557 invoked by uid 98); 1 Nov 2002 04:42:36 -0000 X-Antivirus: nagoya (v4218 created Aug 14 2002) Message-ID: <3DC1FE41.9040403@lbl.gov> Date: Thu, 31 Oct 2002 20:08:33 -0800 From: Jason Novotny User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X; en-US; rv:0.9.4.1) Gecko/20020315 Netscape6/6.2.2 X-Accept-Language: en-us MIME-Version: 1.0 To: Jetspeed Developers List Subject: Re: why do portlets inherit from servlets? References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N That sounds fine in theory, but seems to make the implementation kind of schizophrenic. So if portlets are servlets and they have an entry in a web.xml file and a servlet mapping, then it would seem they are really managed by the servlet container e.g. Tomcat. However portlets don't implement servlets they extend them, so the only calls that the servlet container can make are the init(ServletConfig), service(HttpServletRequest, httpServletResponse) and destroy() methods. How do the init(PortletConfig) initConcrete(PortletSettings) and doView, doEdit, doHelp, etc, methods get called that are defined in the WebSphere portlet API? If portlets are in fact their own objects than they can be managed by a chief servlet otherwise it seems that the portlet container is really a servlet container. Possibly IBM hacked Tomcat as well to make their model fly. I'm beginning to think there is really no good reason for portlets to subclass servlets. Jason Weaver, Scott wrote: >Here is a portion of JSR 168. > >"The Portlet specification will be based on the Servlet specification. It is envisioned that the developer API will be similar to the Servlet API. > >The Portlet specification will restrict the use of functions provided by the Servlet API to a subset that makes sense for components providing fragments of a markup page." > >It's pretty much like David stated below. Use the servlet API pieces for where it makes sense, drop the stuff that doesn't. > >Scott > >>-----Original Message----- >>From: David Sean Taylor [mailto:david@bluesunrise.com] >>Sent: Thursday, October 31, 2002 12:55 AM >>To: Jetspeed Developers List >>Subject: RE: why do portlets inherit from servlets? >> >> >> >>>-----Original Message----- >>>From: Jason Novotny [mailto:jdnovotny@lbl.gov] >>>Sent: Wednesday, October 30, 2002 9:02 PM >>>To: Jetspeed Developers List >>>Cc: david@bluesunrise.com >>>Subject: Re: why do portlets inherit from servlets? >>> >>> >>> >>>Hi David, >>> >>> Thanks for the information. In trying to implement >>>something similar >>>myself, I'm confused as to how to manage the portlet lifecycle if >>>portlets are servlets. For instance, the only method a "manger" >>>servlet, or portlet container, can access of a portlet is the service >>>method thru the RequestDispatcher.include call. How would the >>>init(PortletConfig) or initConcrete(PortletSettings), login and other >>>methods get called? >>>In the other case, where portlets are their own objects and not >>>necessarily servlets, then what about the PortletConfig object, which >>>seems to get its params from the web.xml? Will that be a part of the >>>standard? >>> >>Well wouldn't the servlet interface be just one of the interfaces that a >>portlet may implement, so the container can make standardized calls such >>as >>init on the Portlet (extended) interface. >> >>IMO, there are too many differences between a portlet and servlet. The >>servlet api should be mimicked where needed. >>I personally wouldn't extend a Portlet interface from Servlet. A portlet >>has >>a different lifecycle and request phases. Some Servlet API methods would >>be >>not applicable (or stale) on the Portlet api. Portlets render fragments, >>servlets the entire page. >> >>David >> >> >> >>-- >>To unsubscribe, e-mail: >unsubscribe@jakarta.apache.org> >>For additional commands, e-mail: >help@jakarta.apache.org> >> > -- To unsubscribe, e-mail: For additional commands, e-mail: