Thank you
Now I understand what Rahul meant by portable. Chances of our changing
web servers is slim.
Well, if I had not used digester, I could have put the common war file in
the shared/lib. I am ok with not sharing digester itself but the fact that
all the digester constructed classes need to be put in WEB-INF/lib seems to
be a severe restriction to me.
By the way, has anyone done an analysis of how much it costs to duplicate
the war files in terms of memory?
Thanx again for the reply to you and Rahul.
Menon
jwcarman wrote:
BeanUtils (which Digester uses) uses static variables, so sharing that
particular stuff across webapps can cause some trouble. As Rahul
said, just put the stuff in your WEB-INF/lib directory. It's more
portable that way (you can just plop your war file down in any other
web server if it's constructed this way).
On Sat, Jan 3, 2009 at 5:27 PM, rmenon rmenon...@gmail.com wrote:
Rahul Akolkar wrote:
On Sat, Jan 3, 2009 at 3:51 PM, rmenon rmenon...@gmail.com wrote:
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?
snip/
Generally you want your apps to be self-contained. The servlet
specification talks about the web app and its directory structure,
shared stuff is often container specific (I did mention portability).
Well, from what I understand, at least in tomcat (which is what we use),
there is a shared/lib
directory for jars that are common across applications. These jars need
not be container specific.
And I am not sure what you mean portability? Could you explain a bit
more?
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)?
snap/
I think you mean duplicating libraries in war files for different web
apps with similar application dependencies.
I meant duplicating a jar file that is shared across applications in
each
of the applications's WEB-INF/lib
directories. I would think that there should be a way to put them in
shared/lib directory and still be able to use digester to construct
them.
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.)
snap/
I still think you mean adding the same jars to each WEB-INF/lib -- its
portable and its safe.
-Rahul
Rahul Akolkar wrote:
On Sat, Jan 3, 2009 at 3:44 PM, rmenon rmenon...@gmail.com 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 rmenon...@gmail.com 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: user-unsubscr...@commons.apache.org
For additional commands, e-mail:
