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]
