Return-Path: Delivered-To: apmail-commons-dev-archive@www.apache.org Received: (qmail 82873 invoked from network); 21 Apr 2009 22:32:08 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.3) by minotaur.apache.org with SMTP; 21 Apr 2009 22:32:08 -0000 Received: (qmail 29126 invoked by uid 500); 21 Apr 2009 22:32:07 -0000 Delivered-To: apmail-commons-dev-archive@commons.apache.org Received: (qmail 28994 invoked by uid 500); 21 Apr 2009 22:32:07 -0000 Mailing-List: contact dev-help@commons.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: "Commons Developers List" Delivered-To: mailing list dev@commons.apache.org Received: (qmail 28984 invoked by uid 99); 21 Apr 2009 22:32:07 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 21 Apr 2009 22:32:07 +0000 X-ASF-Spam-Status: No, hits=-0.0 required=10.0 tests=SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (nike.apache.org: domain of ralph.goers@dslextreme.com designates 209.85.146.181 as permitted sender) Received: from [209.85.146.181] (HELO wa-out-1112.google.com) (209.85.146.181) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 21 Apr 2009 22:31:57 +0000 Received: by wa-out-1112.google.com with SMTP id j32so1702988waf.10 for ; Tue, 21 Apr 2009 15:31:36 -0700 (PDT) Received: by 10.115.23.19 with SMTP id a19mr4221026waj.63.1240353096670; Tue, 21 Apr 2009 15:31:36 -0700 (PDT) Received: from ?192.168.10.129? (adsl-66-51-196-164.dslextreme.com [66.51.196.164]) by mx.google.com with ESMTPS id m30sm9956463wag.47.2009.04.21.15.31.34 (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 21 Apr 2009 15:31:35 -0700 (PDT) Message-Id: From: Ralph Goers To: "Commons Developers List" In-Reply-To: <256060.59697.qm@web63302.mail.re1.yahoo.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Subject: Re: commons-logging unsuited for cross-context webapplication invocation usage - migrating to slf4j? Date: Tue, 21 Apr 2009 15:31:32 -0700 References: <49ECDF6E.70502@doit.wisc.edu> <4A30EC8B-ABA6-4DC0-A766-6EB31A33B24A@dslextreme.com> <342A575A-ECF8-4892-A8B8-312B92DBCD8B@dslextreme.com> <25aac9fc0904210801g5cfcb13ao65df7df0a334fb17@mail.gmail.com> <49EE1794.9080201@apache.org> <59305DEC-5809-4BEA-85CE-942CFE6FE65D@dslextreme.com> <256060.59697.qm@web63302.mail.re1.yahoo.com> X-Mailer: Apple Mail (2.930.3) X-Virus-Checked: Checked by ClamAV on apache.org On Apr 21, 2009, at 3:03 PM, John Bollinger wrote: > I confess that I don't understand the portal environment very well, > but if I'm following this correctly then PLUTO-553 is a symptom of a > more fundamental issue: objects in a Pluto portlet cannot rely on > the context classloader to be the correct one from which to obtain > resources. This arises because -- as I understand it -- Pluto > provides portlet isolation analogous to the isolation of distinct > webapps in a servlet container, but unlike a servlet container, it > allows one portlet to invoke methods on the live objects of another, > not changing the context classloader when such cross-context method > invocations occur. > > If I have analyzed that correctly then I would account it a Pluto > bug, not a JCL bug. It is hard to classify something a "bug" when it is working "corectly". The portlet spec requires that a portal container be a webapp and that it be able to deploy and control portlets in the manner in which Pluto is doing it. That could hardly be considered a bug. Think about it this way. The end user sees a page with multiple widgets on it. The end user can interact with any of them. All pluto wants is that the logging that occurs work the same no matter which portlet the end user interacts with. That doesn't seem too unreasonable to me. What your answer basically says is, commons logging only supports the servlet spec, not the portlet spec. I guess this falls in line with https://issues.apache.org/jira/browse/LOGGING-124? Out of curiosity, if commons-logging doesn't work in an OSGi container then how can any commons components do logging there? Ralph --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org For additional commands, e-mail: dev-help@commons.apache.org