Return-Path: Delivered-To: apmail-commons-user-archive@www.apache.org Received: (qmail 12964 invoked from network); 3 Jan 2009 20:47:54 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2) by minotaur.apache.org with SMTP; 3 Jan 2009 20:47:54 -0000 Received: (qmail 78470 invoked by uid 500); 3 Jan 2009 20:47:50 -0000 Delivered-To: apmail-commons-user-archive@commons.apache.org Received: (qmail 78385 invoked by uid 500); 3 Jan 2009 20:47:50 -0000 Mailing-List: contact user-help@commons.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: "Commons Users List" Delivered-To: mailing list user@commons.apache.org Received: (qmail 78374 invoked by uid 99); 3 Jan 2009 20:47:50 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Sat, 03 Jan 2009 12:47:50 -0800 X-ASF-Spam-Status: No, hits=0.2 required=10.0 tests=SPF_PASS,WHOIS_MYPRIVREG X-Spam-Check-By: apache.org Received-SPF: pass (nike.apache.org: domain of rahul.akolkar@gmail.com designates 209.85.219.13 as permitted sender) Received: from [209.85.219.13] (HELO mail-ew0-f13.google.com) (209.85.219.13) by apache.org (qpsmtpd/0.29) with ESMTP; Sat, 03 Jan 2009 20:47:41 +0000 Received: by ewy6 with SMTP id 6so7551381ewy.18 for ; Sat, 03 Jan 2009 12:47:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references; bh=ZmombLCsqJ0xxV0xNJr96u+rw16Um+7Qgvbyfxj/XKM=; b=cZ935kVxIVFSK3GTlzq8u6DuzgeFfvgcgx9hgx6XMNnpWJInn/4j2sOy2MdjCJYpq1 ySPk4GP+uS2DV9ZcNWACfP5+h7QTkzb9z5CXqNEevM1Cx3DuC/ZiPAsjs+3rbPxHpfsJ YMyMTgk7REJ0XdeiWF3CS0LUa6BAD7FRmmKrI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=tnHrKpxJngtNgRkbGRBxIPdKXETC8NQRHAEMUHjUjEymi9MByxoIfzgBSWWHW80tYU H7DFvhIMk3W+57qaoZ1x7jd/m9lmorZSNL5Iy7BdYCDgE6BVGc4D4623CZGZGFLlU1NF G0J7FgTc2cJlDw296WVXRItpFoAqrXphWsCTM= Received: by 10.210.109.10 with SMTP id h10mr22432707ebc.10.1231015640783; Sat, 03 Jan 2009 12:47:20 -0800 (PST) Received: by 10.210.53.9 with HTTP; Sat, 3 Jan 2009 12:47:20 -0800 (PST) Message-ID: Date: Sat, 3 Jan 2009 15:47:20 -0500 From: "Rahul Akolkar" To: "Commons Users List" Subject: Re: Digester 1.8 classloader issue when using tomcat In-Reply-To: <21269147.post@talk.nabble.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <21268177.post@talk.nabble.com> <21269147.post@talk.nabble.com> X-Virus-Checked: Checked by ClamAV on apache.org On Sat, Jan 3, 2009 at 3:44 PM, rmenon wrote: > > Can you please elaborate? Are you suggesting that I should just package all > three jar files in WEB-INF/lib? > If they are needed by the said web app, yes. -Rahul > Rahul Akolkar wrote: >> >> On Sat, Jan 3, 2009 at 2:14 PM, rmenon wrote: >>> >>> Hi >>> I have three jar files: common, webapp-common, my-webapp.jar. >>> common- can be used by non web apps >>> webapp-common - common stuff shared by web apps. >>> my-webapp.jar - a particular web app. >>> >>> I am using digester to build my classes for the app my-webapp.jar. In >>> the >>> digester rules, I have classes that are in all three jar files. Now, >>> ideally >>> speaking, I should be able to put the webapp-cmmon and common jar files >>> in >>> the shared/lib and the my-webapp.jar in WEB-INF/lib. However, that >>> results >>> in the digester failing with "NoClassDefFoundException". The problem goes >>> away if we put all three jars in the WEB-INF/lib since the digester class >>> loader can see those classes. However, the common jar is already in the >>> shared/lib being used by other apps. I added some new "common" stuff for >>> the >>> my-webapp.jar and hence running into this issue. >>> >>> My latest thinking is to separate out the portion of the classes being >>> used >>> by the my-webapp.jar from the common jar file into its own jar. Then I >>> can >>> bundle the webapp-common ahd my-webapp.jar in to the WEBINF/lib and >>> retain >>> the common jar in the shared/lib. Is there a better approach? What is the >>> best practice in this scenario. Does someone have an idea of overhead in >>> terms of performance etc if we "duplicate" jar files in each app instead >>> of >>> sharing them in common/lib? What I do not like about this issue is that I >>> think this issue would not be there if I was creating objects without >>> using >>> digester - so a way to use the approach (where I can access the common >>> classes from digester) would be really ideal in my opinion. >>> >>> I did search the google and also this forum - I note that someone >>> suggested >>> to always bundle each jar files within the web app itself separately. >>> What >>> is the rationale for that? >>> >> >> >> Portability, potential trouble with statics etc. Also, digester itself >> (and beanutils in particular) should never be shared. >> >> -Rahul >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: user-unsubscribe@commons.apache.org >> For additional commands, e-mail: user-help@commons.apache.org >> >> >> > > -- > View this message in context: http://www.nabble.com/Digester-1.8-classloader-issue-when-using-tomcat-tp21268177p21269147.html > Sent from the Commons - User mailing list archive at Nabble.com. > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: user-unsubscribe@commons.apache.org > For additional commands, e-mail: user-help@commons.apache.org > > --------------------------------------------------------------------- To unsubscribe, e-mail: user-unsubscribe@commons.apache.org For additional commands, e-mail: user-help@commons.apache.org