Return-Path: X-Original-To: apmail-tiles-users-archive@minotaur.apache.org Delivered-To: apmail-tiles-users-archive@minotaur.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id E89D99B73 for ; Wed, 15 Aug 2012 21:52:33 +0000 (UTC) Received: (qmail 22002 invoked by uid 500); 15 Aug 2012 21:52:33 -0000 Delivered-To: apmail-tiles-users-archive@tiles.apache.org Received: (qmail 21926 invoked by uid 500); 15 Aug 2012 21:52:33 -0000 Mailing-List: contact users-help@tiles.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: users@tiles.apache.org Delivered-To: mailing list users@tiles.apache.org Received: (qmail 21917 invoked by uid 99); 15 Aug 2012 21:52:32 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 15 Aug 2012 21:52:32 +0000 X-ASF-Spam-Status: No, hits=1.2 required=5.0 tests=MISSING_HEADERS,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: domain of mail@nlebas.net designates 87.98.221.115 as permitted sender) Received: from [87.98.221.115] (HELO ein.nlebas.net) (87.98.221.115) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 15 Aug 2012 21:52:26 +0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=nlebas.net; s=net1; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:References:Subject:CC:MIME-Version:From:Date:Message-ID; bh=02oqzbMkz5SArGIozNKvZHQ29D02eYDSmXiuxIA041s=; b=k2TaPmdD7LsFWTH81e45QLT397ZuUW+Cd3y5mJZJ084AI5StmUTDg0KFAdoC1kLJEOWXD+D62+iGQgxTjfj3rPATHn3j40kuED5kF2EWncVggzPKlJa2sjG1/Plt3hxeh/APgEXZPRuFZnK1S4ldjMKbDPoAISywrWUOr42mruE=; Received: from nlebas.net ([178.33.41.162] helo=[192.168.2.53]) by ein.nlebas.net with esmtpsa (TLSv1:CAMELLIA256-SHA:256) (Exim 4.77) (envelope-from ) id 1T1lVU-0007Lz-0H for users@tiles.apache.org; Wed, 15 Aug 2012 23:52:04 +0200 Message-ID: <502C1A01.2000704@nlebas.net> Date: Wed, 15 Aug 2012 17:52:01 -0400 From: Nicolas LE BAS User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:14.0) Gecko/20120714 Thunderbird/14.0 MIME-Version: 1.0 CC: users@tiles.apache.org Subject: Re: Tiles 2.2.2 and portlets References: <50293DFE.4040100@gmail.com> <50295EA1.5000003@nlebas.net> <502A71E4.7050705@nlebas.net> <502AC4A1.2080807@gmail.com> <502BD3F7.1060000@nlebas.net> <502BEC74.4050803@gmail.com> In-Reply-To: <502BEC74.4050803@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Checked: Checked by ClamAV on apache.org On 12-08-15 02:37 PM, Ephemeris Lappis wrote: > I think It's likely impossible anyway in portlets, since, for what I > know, there's no standard way to get the servlet request from the > portlet requests (action, render), and attributes set on these seem to > be local and not visible from Tiles... You can't get the ServletRequest from the PortletRequest indeed, but when you call requestDispatcher.include on the URL of a servlet, that servlet receives a ServletRequest. And I believe this ServletRequest comes with the same attributes that were set on the RenderRequest. You say these attributes are not visible from Tiles... where are they visible then? Are they visible from JSPs? I think you may be confusing "definition attributes" with "request attributes", both are visible from Tiles in different ways. > > The last point I want to check is the way a pure servlet filter will be > activated depending on the portlet container or the application server, > and the possible interferences between distinct portlet web applications... I can't help here... But please let us know of your findings, if this is indeed the mainstream way of using Portlets, we should probably make Tiles compatible with it. Good luck Nick