Mailing-List: contact dev-help@commons.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Commons Developers List" <dev@commons.apache.org>
Received-SPF: pass (nike.apache.org: local policy)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
  s=s1024; d=yahoo.com;
  h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Subject:To:In-Reply-To:MIME-Version:Content-Type;
  b=jdUwIprIm9GiZ6eFKcV1uANwtuxout3PUF9n8HjUPZtPt0wYtce1IgK4xC/1MgvpX1eOb3zxOyMOcYStLOsiyfzpQOW9vHISSiSEVI/kdza5jfMLJIvPPh/e1qI6hsrjxBlx15UBLsdhQieAyOKRWJCVgTgk4kFpgtQaEHG32xY=;
Message-ID: <256060.59697.qm@web63302.mail.re1.yahoo.com>
References: <49ECDF6E.70502@doit.wisc.edu>
 <4A30EC8B-ABA6-4DC0-A766-6EB31A33B24A@dslextreme.com>
 <gsjpo5$d12$1@ger.gmane.org>
 <342A575A-ECF8-4892-A8B8-312B92DBCD8B@dslextreme.com>
 <e75283b10904210718i5d8010cem91f45f428c07e01d@mail.gmail.com>
 <25aac9fc0904210801g5cfcb13ao65df7df0a334fb17@mail.gmail.com>
 <e75283b10904211109rfe83351u8e0de4275730d927@mail.gmail.com>
 <B82247CB-623A-47A8-8F2F-E7E6C1F713AE@dslextreme.com>
 <49EE1794.9080201@apache.org>
 <59305DEC-5809-4BEA-85CE-942CFE6FE65D@dslextreme.com>
Date: Tue, 21 Apr 2009 15:03:17 -0700 (PDT)
From: John Bollinger <thinman42@yahoo.com>
Subject: Re: commons-logging unsuited for cross-context webapplication
 invocation usage - migrating to slf4j?
To: Commons Developers List <dev@commons.apache.org>
In-Reply-To: <59305DEC-5809-4BEA-85CE-942CFE6FE65D@dslextreme.com>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="0-288016313-1240351397=:59697"

--0-288016313-1240351397=:59697
Content-Type: text/plain; charset=us-ascii

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.


John


________________________________
From: Ralph Goers <ralph.goers@dslextreme.com>
To: Commons Developers List <dev@commons.apache.org>
Sent: Tuesday, April 21, 2009 3:25:32 PM
Subject: Re: commons-logging unsuited for cross-context webapplication invocation usage - migrating to slf4j?


On Apr 21, 2009, at 11:59 AM, Dennis Lundberg wrote:

>> 
> 
> I'm not that experienced in writing portlets or how the portlet
> container works. Can you please try to explain in more detail what the
> problem is.
> 
> Commons Logging works great in a servlet container like Tomcat. Every
> webapp can have their own version of commons-logging and their own
> configuration. How does the portlet container use case differ from this?
> 
> Do you configure Commons Logging explicitly, by using a
> commons-logging.properties file or are you relying on auto discovery? In
> my experience you you should *always* configure the logging
> implementation explicitly if you want deterministic results.
> 

As I said in an earlier post, I follow the various portlet mailing lists but really have very little to do with the issue they are experiencing. It is documented at http://issues.apache.org/jira/browse/PLUTO-553.

In a nutshell though, the Portal is a War. Individual portlets are packaged as separate war files and are run under the direction of the main portal war. They seem to want all the portlets to use the logging configuration of the portal. Personally, I'm not sure what they are saying they want makes sense, but I guess the point is that even if it doesn't they should still be able to do it.

Ralph

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org


--0-288016313-1240351397=:59697--