Well, Can you please elaborate a bit more? My question is why should we reload the same classes multiple times for a jar file that is shared by multiple web apps? Also, if I do not use digester, then this is not an issue - so what are people who use digester doing (apart from duplicating war files)? I do not like the idea of duplicating same war files for each web app - so is there a good reason to do that (apart from being a workaround for problems with digester.)
Rahul Akolkar wrote: > > On Sat, Jan 3, 2009 at 3:44 PM, rmenon <[email protected]> wrote: >> >> Can you please elaborate? Are you suggesting that I should just package >> all >> three jar files in WEB-INF/lib? >> > <snip/> > > If they are needed by the said web app, yes. > > -Rahul > > >> Rahul Akolkar wrote: >>> >>> On Sat, Jan 3, 2009 at 2:14 PM, rmenon <[email protected]> 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? >>>> >>> <snip/> >>> >>> Portability, potential trouble with statics etc. Also, digester itself >>> (and beanutils in particular) should never be shared. >>> >>> -Rahul >>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: [email protected] >>> For additional commands, e-mail: [email protected] >>> >>> >>> >> >> -- >> 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: [email protected] >> For additional commands, e-mail: [email protected] >> >> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > > > -- View this message in context: http://www.nabble.com/Digester-1.8-classloader-issue-when-using-tomcat-tp21268177p21269213.html Sent from the Commons - User mailing list archive at Nabble.com. --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
